Тестирование производительности в нескольких SQL-запросах - PullRequest
4 голосов
/ 27 марта 2012

Я работаю над повышением эффективности некоторых запросов SQL на SQL-Server-2008.Существуют разные способы выполнения каждого запроса, и я хочу найти самый быстрый из них.

Однако проблема, с которой я сталкиваюсь, заключается в том, что у меня возникают проблемы с определением того, что на самом деле выполняется быстрее.В идеале я мог бы просто выполнить каждый запрос один за другим и посмотреть, какой из них выполняется быстрее всего.В идеале ...

Проблема в том, что SQL слишком умен для моего вкуса.При построении этих запросов я запускаю их несколько раз.Когда я это делаю, эффективность запросов повышается сама по себе.Это я изобразил из-за некоторых закулисных вещей, которые делает SQL.Что это?Как я могу избежать этого?

Например, я запускаю запрос один раз, и это занимает 30 секунд.Я запускаю его снова, и это занимает 10 секунд.Чем больше я запускаю запрос, тем быстрее он выполняется.

Итак ... Есть ли способ "очистки кэша" или что-то подобное, что было бы в SQL?Я хочу получить точное указание того, какой запрос будет выполняться быстрее.В качестве альтернативы, какой наилучший способ сделать тип тестирования, который мне нужен?

Любая информация по этой теме будет принята как действительный ввод.

Ответы [ 3 ]

8 голосов
/ 27 марта 2012

Когда запрос запускается первым, скорее всего, данные все еще находятся на диске, SQl Server должен извлечь эти данные, когда вы выполняете тот же запрос, данные уже находятся в ОЗУ и, следовательно, они будут намного быстрее, чем поступать на диск

Запустите DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE, чтобы очистить кэш без перезапуска

Вам нужно посмотреть планы выполнения, статистику ввода-вывода и статистику времени, чтобы действительно увидеть, что происходит.в плане ищите конверсии, а также просмотры (если хотите, ищите, если возможно).

См. также Статистика клиентов в SSMS.Проверьте время выполнения

1 голос
/ 27 марта 2012

Улучшение скорости, которое вы видите, является результатом кеша запросов базы данных.Большинство механизмов реляционных БД имеют эту функцию, которая кэширует результат запроса до тех пор, пока таблицы (и), из которых вы читаете, не будут обновлены.

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

0 голосов
/ 27 марта 2012

Включите фактический план выполнения и выполните следующую команду:

CHECKPOINT; 
GO 
DBCC DROPCLEANBUFFERS; 
GO
...