Manage how SQL Server stores and evicts data pages and execution plans to improve performance or troubleshoot issues.
Adjusting cache lets you flush problematic execution plans, measure true I/O costs, or prevent parameter sniffing issues. It is a quick, non-destructive way to reset performance baselines.
Run DBCC FREEPROCCACHE;
to remove all cached execution plans. Use it only in staging or during off-hours because it forces recompilation of every query.
Yes.Retrieve the plan_handle from sys.dm_exec_cached_plans
and pass it: DBCC FREEPROCCACHE (plan_handle);
This targets one bad plan without disrupting others.
Execute DBCC DROPCLEANBUFFERS;
after CHECKPOINT;
to flush data pages from memory. Ideal for benchmarking disk performance.
Add the query hint OPTION (RECOMPILE)
.SQL Server compiles, runs, and discards the plan immediately, preventing parameter sniffing.
Dynamic management views such as sys.dm_exec_query_stats
, sys.dm_exec_cached_plans
, and sys.dm_exec_query_plan
expose plan reuse counts, memory size, and SQL text.
Prefer targeted plan clears, schedule global clears during low traffic, monitor recompilations with sys.dm_exec_query_stats
, and always test in lower environments first.
.
No. It only removes in-memory copies; data remains on disk.
Query sys.dm_exec_cached_plans
ordered by size_in_bytes
to identify heavy plans.
Use sparingly; constant recompilation increases CPU. Consider plan guides or parameterization instead.