Как очистить кэш запросов 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);
обратите внимание, что ни DBCC DROPCLEANBUFFERS;
, ни DBCC FREEPROCCACHE;
поддерживается в хранилище данных SQL Azure / SQL.
однако, если вам нужно сбросить кэш плана в SQL Azure, вы можете изменить одну из таблиц в запросе (например, просто добавьте, а затем удалите столбец), это будет иметь побочный эффект удаления плана из кэша.
Я лично делаю это как способ тестирования производительности запросов без необходимости иметь дело с кэшированных планов.