SQL Server: nop обновления постепенно медленнее, почему?

Question

Каждую минуту эта программа считывает набор записей из um DB e, которая реплицирует их в другой БД. В 99% случаев он состоит из операции Нет, потому что данные не изменились.

Проблема в том, что отдельные перезаписи становились все медленнее. С 2500 записей стало заметно.

Если данные не меняются, почему SQL постепенно замедляется?

Подробнее: тогда я использовал GUID в качестве Первичных ключей (плохой я, я знаю). Но, насколько я понимаю, фрагментация возникает только в том случае, если новые вставки или обновления изменяют размер данных в обоих случаях, вызывая разбиение страниц. Моя теория заключается в том, что эти обновления nop являются фрагментацией чего-то (не легко различимы) и вызывают увеличение латентности. Возможно, SQL-сервер реализует это обновление как транзакцию удаления/вставки?

Answer 1

Фрагментация - не единственная причина, по которой случайные GUID бывают медленными. Требуется больше ввода-вывода, так как строки распределяются равномерно по всей таблице. Это часто приводит к производительности, которая постепенно ухудшается по мере увеличения размера базы данных, особенно с использованием традиционных прядильных сред. Помните, что данные должны сначала считываться в память, даже если данные не обновляются. Вероятность того, что страница с необходимой строкой уже находится в памяти, сводится к чисто случайным ключевым запросам.

Если вы должны использовать GUID, рассмотрите последовательное значение, присвоенное NEWSEQUENTIALID или UuidCreateSequential и некоторую замену байтов. См. Мой комментарий Improving Uniqueidentifier Performance для примера кода и дополнительные сведения об этой общей проблеме с производительностью.