Тестирование скорости запроса с использованием некэшированных данных?

#sql #sql-server #tsql

#sql #sql-сервер #tsql

Вопрос:

SQL Server 2014. Выполнение запроса, который у меня есть, занимает 44 секунды при первом запуске. После этого требуется 6 секунд. Я уверен, что это связано с тем, что данные кэшируются в памяти (и, возможно, потому, что план запроса также кэшируется). Я хочу найти способы ускорить мой запрос, чтобы в первый раз это заняло 6 секунд, но это сложно проверить, когда все кэшируется.

Как я могу заставить свой запрос НЕ использовать кэшированные данные? Или, другими словами, как я могу заставить мой запрос выполняться каждый раз так, как будто это происходит в первый раз?

Я попытался добавить опцию recompile , но это ничего не изменило.

Спасибо!

1. DBCC DROPCLEANBUFFERS заставляет SQL Server удалять все (неизмененные) данные, которые он помещает в буферный кэш; DBCC FREEPROCCACHE отбрасывает планы запросов. Они распространяются на весь сервер и оказывают огромное влияние на рабочую машину, поэтому используйте их только на машине, которую вы в значительной степени используете исключительно самостоятельно.

2. Вы намерены измерить производительность запроса или системы ввода-вывода? Для последнего подойдет «теплый» кеш.

Ответ №1:

Похоже, вы ищете команду DBCC DROPCLEANBUFFERS SQL Server. Из документации:

Используйте DBCC DROPLEANBUFFERS для тестирования запросов с холодным буферным кэшем без выключения и перезапуска сервера.

Эта команда может использоваться в сочетании с DBCC FREEPROCCACHE :

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

Отказ от ответственности: пожалуйста, рассмотрите последствия такой команды перед ее запуском; это должно использоваться только в целях тестирования в непроизводственных средах!

1. Спасибо. Я знал о DBCC FREEPROCCACHE и последствиях его использования в производственной системе. Не знал о DROPLEANBUFFERS. К сожалению, я работаю в производственной системе и надеялся, что есть что-то вроде опции перекомпиляции, чтобы указать ей игнорировать кеш. Но это действительно очень помогает, когда я нахожусь в нашей системе разработки. Большое спасибо!

2. Обратите внимание, что это CHECKPOINT было необходимо раньше DBCC DROPCLEANBUFFERS . Кроме того, SQL Server выполняет чтение в полном объеме, а не на одной странице, когда кэш не прогрет ( dbdelta.com/performance-testing-with-dbcc-dropcleanbuffers ).

Ответ №2:

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

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