SQL-Ex blog

Выполнение DBCC FREEPROCCACHE с параметром говорит о том, что нужно просто сбросить один план и перекомпилировать его. Это оказывает очень незначительное влияние и не сильно отличается от того, как если бы вы просто немного изменили запрос, заставив его перекомпилировать.

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

Чтобы использовать DBCC FREEPROCCACHE, вам не обязательно указывать какие-либо аргументы. Просто выполните команду в окне запросов, подключенного к базе данных, для которой вы хотите очистить процедурный кэш.

Вот пример использования DBCC FREEPROCCACHE для очистки процедурного кэша в базе данных:

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

-- Очистка процедурного кэша в базе данных "MyDatabase"

DBCC FREEPROCCACHE ('MyDatabase');

На выходе DBCC FREEPROCCACHE будет выведено сообщение, указывающее была ли операция успешной. Если операция прошла успешно, процедурный кэш будет очищен, и все хранимые процедуры, триггеры и ad hoc пакеты Transact-SQL будут удалены из кэша.

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

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

Вот вопрос, который я получил сегодня от друга, и я думаю, что это был бы хороший пост, объясняющий детали:

Стив,
у меня вопрос по DBCC FREEPROCCACHE. Я использовал sp_blitzcache от Brent, и он показывает, что есть один ужасный запрос (я уже это знаю, поскольку запустил его и отменил примерно через 10 минут).
Он давал мне DBCC FREEPROCCACHE (0x03000700FA15020D5EAA560063A7000001000000000000000000000000000000000000000000000000000000);
На что это может повлиять?
Приложение обновлялось около часа, прежде чем я выполнил его.

Итак, DBCC FREEPROCCACHE берет созданные планы и выбрасывает их из памяти, заставляя SQL Server перекомпилировать план при последующем выполнении запроса, который бы использовал план, находившийся в кэше до его сброса. Опасность состоит в том, что если вы выполняете DBCC FREEPROCCACHE без параметров, он очистит весь кэш планов, вынуждая перекомпилировать каждый план так, как будто вы просто перезапустили SQL Server (НЕ ДЕЛАЙТЕ ЭТОГО).

Ссылки по теме

1. Перекомпиляция запроса SQL и её влияние на производительность


2. Как отследить производительность запросов, которые используют хинты RECOMPILE


3. Почему Parameter Sniffing не всегда плохо (хотя обычно так и есть)


4. 5 причин, которые следует рассмотреть при падении производительности запроса


5. Под капотом SQL Server. Основы кэширования данных