Почему лучший уровень изоляции означает лучшую производительность в SQL Server
При измерении уровня на моем запросе я придумал зависимость между уровнем изоляции и прошедшее время, которое было удивительно мне
READUNCOMMITTED - 409024
READCOMMITTED - 368021
REPEATABLEREAD - 358019
SERIALIZABLE - 348019
Левый столбец является подсказкой таблицы, и правый столбец является прошедшим временем в микросекундах (sys.dm_exec_query_stats.total_elapsed_time). Почему лучший уровень изоляции дает лучшую производительность? Это - машина разработки, и никакого параллелизма вообще не происходит. Я ожидал бы, что READUNCOMMITTED будет постившимся должным к меньшему количеству блокировки наверху.
Обновление: Я действительно измерял это с
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
выпущенный и Профилировщик подтверждает, что нет никакого случая удачных обращений в кэш.
1 ответ
Прежде всего, вам нужно повторно запустить запрос на каждом уровне изоляции и усреднить результат, отбрасывая тот, у которого есть максимальное время. Это устранит влияние разогрева буфера: вы хотите, чтобы все прогоны выполнялись в теплом кэше, а не чтобы один запрос прогревал кеш и платил штраф за сравнение.
Затем вам необходимо убедиться, что вы выполняете измерения в реалистичном сценарии параллелизма. ЕСЛИ у вас будут обновления / вставки / удаления, происходящие в реальной жизни, вы должны добавить их в свой тест, поскольку они будут сильно влиять на чтения при различных уровнях изоляции. Последнее, что вы хотите, - это сделать вывод «сериализуемые чтения - самые быстрые, давайте использовать их везде», а затем наблюдать, как система расплавляется в процессе производства, потому что все сериализуется.
Помимо этого, единственный уровень изоляции, который на законных основаниях быстрее, - это грязное чтение, поскольку оно не требует блокировок. Моментальный снимок, зафиксированный при чтении (который вы не измеряли), также не получает блокировок, но влияет на производительность в целом из-за накладных расходов на управление версиями строк.