Как очистить кэш запросов SQL Server?

у меня есть простой запрос, запущенный против SQL Server 2005

SELECT * 
FROM Table 
WHERE Col = 'someval'

первый раз, когда я выполняю запрос, может занять > 15 secs. Последующие выполнения возвращаются в < 1 sec.

как заставить SQL Server 2005 не использовать кэшированные результаты? Я пробовал бежать

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE

но это, похоже, не влияет на скорость запроса (все еще < 1 sec).

5 ответов


вот некоторые хорошие объяснения. зацени.

http://www.mssqltips.com/tip.asp?tip=1360

CHECKPOINT; 
GO 
DBCC DROPCLEANBUFFERS; 
GO

из связанной статьи:

Если все тестирование производительности проводится в SQL Server, лучшим подходом может быть выдача контрольной точки, а затем команда DBCC DROPCLEANBUFFERS. Хотя процесс контрольных точек является автоматическим внутренним системным процессом в SQL Server и происходит регулярно, важно, чтобы эту команду писать все "грязные" страницы в текущей базе данных на диск и очистки буферов. Затем можно выполнить команду DBCC DROPCLEANBUFFERS для удаления всех буферов из пула буферов.


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

OPTION (OPTIMIZE FOR UNKNOWN)

тогда ваш запрос будет выглядеть следующим образом

select * from Table where Col = 'someval' OPTION (OPTIMIZE FOR UNKNOWN)

EXEC sys.sp_configure N'max server memory (MB)', N'2147483646'
GO
RECONFIGURE WITH OVERRIDE
GO

какое значение вы указываете для памяти сервера, не важно, если оно отличается от текущего.

кстати, то, что вызывает ускорение, - это не кэш запросов, а кэш данных.


восемь различных способов очистки кэша плана

1. Удалите все элементы из кэша плана для всего экземпляра

DBCC FREEPROCCACHE;

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

2. Очистите кэш плана для всего экземпляра и подавите регулярное завершение сообщение

"выполнение DBCC завершено. Если инструкция DBCC выдает сообщения об ошибках, обратитесь к системному администратору."

DBCC FREEPROCCACHE WITH NO_INFOMSGS;

3. Очистите специальный и подготовленный кэш плана для всего экземпляра

DBCC FREESYSTEMCACHE ('SQL Plans');

4. Очистите специальный и подготовленный кэш плана для одного пула ресурсов

DBCC FREESYSTEMCACHE ('SQL Plans', 'LimitedIOPool');

5. Очистите весь кэш плана для одного пула ресурсов

DBCC FREEPROCCACHE ('LimitedIOPool');

6. Удаляет все элементы из кэша планов для одной базы данных (не работает в SQL Azure)

-- Get DBID from one database name first
DECLARE @intDBID INT;
SET @intDBID = (SELECT [dbid] 
                FROM master.dbo.sysdatabases 
                WHERE name = N'AdventureWorks2014');

DBCC FLUSHPROCINDB (@intDBID);

7. Очистить кэш плана для текущей базы данных

USE AdventureWorks2014;
GO
-- New in SQL Server 2016 and SQL Azure
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

8. Удалить один план запроса из кэша

USE AdventureWorks2014;
GO

-- Run a stored procedure or query
EXEC dbo.uspGetEmployeeManagers 9;

-- Find the plan handle for that query 
-- OPTION (RECOMPILE) keeps this query from going into the plan cache
SELECT cp.plan_handle, cp.objtype, cp.usecounts, 
DB_NAME(st.dbid) AS [DatabaseName]
FROM sys.dm_exec_cached_plans AS cp CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st 
WHERE OBJECT_NAME (st.objectid)
LIKE N'%uspGetEmployeeManagers%' OPTION (RECOMPILE); 

-- Remove the specific query plan from the cache using the plan handle from the above query 
DBCC FREEPROCCACHE (0x050011007A2CC30E204991F30200000001000000000000000000000000000000000000000000000000000000);

источник 1 2 3


обратите внимание, что ни DBCC DROPCLEANBUFFERS;, ни DBCC FREEPROCCACHE; поддерживается в хранилище данных SQL Azure / SQL.

однако, если вам нужно сбросить кэш плана в SQL Azure, вы можете изменить одну из таблиц в запросе (например, просто добавьте, а затем удалите столбец), это будет иметь побочный эффект удаления плана из кэша.

Я лично делаю это как способ тестирования производительности запросов без необходимости иметь дело с кэшированных планов.

подробнее о Кэш процедур SQL Azure здесь