2010-03-15 4 views
7

При измерении производительности на мой запрос я пришел с зависимостью между уровнем изоляции и истекшее время, что было удивительно для меняПочему лучше уровень изоляции означает более высокую производительность в SQL Server

READUNCOMMITTED - 409024 
READCOMMITTED - 368021 
REPEATABLEREAD - 358019 
SERIALIZABLE - 348019 

левый столбец таблицы намек, и правый столбец - истекшее время в микросекундах (sys.dm_exec_query_stats.total_elapsed_time). Почему лучший уровень изоляции дает лучшую производительность? Это машина разработки, и никакой параллелизм не происходит. Я ожидал бы, что READUNCOMMITTED будет голодом из-за меньшего количества накладных расходов.

Обновление: Я сделал измерить с

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE 

выданную и Profiler подтверждает то вы кэш не хиты происходит.

+0

У меня есть такая привычка, спасибо за напоминание. Ремус предоставил довольно ценный вклад, хотя я все еще надеюсь получить представление о том, почему явление, которое я наблюдаю, происходит. –

ответ

4

Прежде всего, вам нужно выполнить запрос повторно под каждым уровнем изоляции и усреднить результат, отбросив одно с максимальным временем. Это устраняет эффект разминки буфера: вы хотите, чтобы все прогоны находились в теплом кеше, а не один запрос нагревал кеш и платил штраф за сравнение.

Затем вы должны убедиться, что вы измеряете реалистичный сценарий параллелизма. Если у вас появятся обновления/вставки/удаления в реальной жизни, то вы должны добавить их в свой тест, так как они будут сильно влиять на . читает при различном уровне изоляции. Последнее, что вы хотите, состоит в том, чтобы заключить, что «сериализуемые чтения являются самыми быстрыми, позволяют использовать их повсюду», а затем наблюдать, как система тает в процессе производства, потому что все сериализовано.

Помимо этого, только уровень изоляции, который является законно более быстрым, является грязным, поскольку он не получает блокировок. Чтение зафиксированного моментального снимка (которое вы не измеряли) также не получает блокировок, но оно влияет на производительность в целом из-за чрезмерных расходов на управление версиями.

+0

Подпишитесь на мой вопрос, чтобы узнать некоторые моменты вашего ответа. Под «грязным чтением» вы подразумеваете READUNCOMMITTED, правильно? –

+0

1) Выполнение запроса в холодном кэше неточно. Ваши производственные запросы не будут работать в холодном кэше, вы будете оптимизировать нереалистичный сценарий, и вы не будете измерять запрос, вы действительно измеряете пропускную способность диска. Вам также нужно измерять производительность в теплом кеше, а также отслеживать как (холодное время работы, так и время работы). 2) грязные чтения считаются незафиксированными. –

+0

Насколько важен кеш для большого запроса (миллионы строк), который при обычных обстоятельствах работает только один раз для конкретных данных? –

0

Теперь, когда я понимаю уровни изоляции лучше, я вижу, что лучший уровень изоляции может позволить некоторые умные оптимизации. Например, как только транзакция считывает данные, уровень изоляции данных может указывать на то, что следует использовать эти данные до конца, а не пытаться перечитать их с диска.

Мне все еще было бы интересно прочитать некоторые подробные сведения об этом.