При сравнении времени выполнения двух разных запросов важно очистить кеш, чтобы убедиться, что выполнение первого запроса не влияет на производительность второго.
В поиске Google я мог найти эти команды:
DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE
На самом деле, мои запросы занимают более реалистичное время после нескольких выполнений, чем раньше. Однако я не уверен, что это рекомендуемая техника.
Какая лучшая практика?
sql-server
performance-testing
andrerpena
источник
источник
DBCC FLUSHPROCINDBПроизошла ошибка при запуске : неверное число параметров было указано в инструкции DBCC.DECLARE @myDb AS INT = DB_ID(); DBCC FLUSHPROCINDB(@myDb); GOотсюда: stackoverflow.com/questions/7962789/…Поздний ответ, но может быть полезен для других читателей
DBCC DROPCLEANBUFFERS - часто используемая команда для тестирования запросов и измерения скорости их выполнения. Эта команда (при запуске) оставляет только грязные страницы, которые на самом деле представляют собой небольшую часть данных. Он удаляет все чистые страницы для всего сервера.
Имейте в виду, что эту команду не следует запускать в производственной среде. Выполнение этой команды приведет в основном к пустому буферному кешу. Выполнение любого запроса после выполнения команды DBCC DROPCLEANBUFFERS будет использовать физическое чтение для возврата данных в кэш, который, скорее всего, будет намного медленнее, чем память.
Опять же, относитесь к этой команде аналогично DBCC FREEPROCCACHE - ее не следует запускать на каком-либо производственном сервере, если вы абсолютно не знаете, что делаете.
Это может быть полезным инструментом разработки, поскольку вы можете многократно выполнять запрос в среде тестирования производительности без каких-либо изменений в скорости / эффективности из-за кэширования данных в памяти.
Узнайте больше на: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/
источник
Мне всегда говорили использовать:
Из MSDN :
источник
DBCC FREEPROCCACHEочистить любые кэшированные планы выполнения ...Другие ответы правильны о причинах, чтобы не бежать
DBCC FREEPROCCACHE. Однако есть также несколько причин для этого:Если вы хотите сравнить два разных запроса или процедуры, которые пытаются сделать одно и то же по-разному, они могут попасть на одни и те же страницы. Если вы наивно выполняете запрос № 1, а затем запрос № 2, второй может быть намного быстрее просто потому, что эти страницы были кэшированы первым запросом. Если вы очищаете кеш перед каждым выполнением, они начинают работать равномерно.
Если вы хотите протестировать производительность «горячего» кэша, обязательно выполняйте запросы несколько раз, чередуясь и отбрасывая первые несколько запусков. Средние результаты.
Скажем, у вас есть запрос, который занимает одну секунду для горячего кэша, но одну минуту для холодного кэша. Оптимизация, которая делает запрос в памяти на 20% медленнее, но связанный с вводом-выводом запрос на 20% быстрее, может быть большим выигрышем: при обычных операциях никто не заметит дополнительные 200 мс при нормальных обстоятельствах, но если что-то заставляет запрос запустить против диска, 48 секунд вместо 60 может спасти продажу.
Это менее важно для современных систем с десятками гигабайт памяти и относительно быстрым хранилищем SAN и SSD, но это все еще имеет значение. Если какой-то аналитик выполнит запрос массивной таблицы на вашу базу данных OLTP, которая уничтожит половину вашего буферного кеша, эффективные для хранения запросы вернут вас быстрее.
источник