SQL Server Plan Cache Invalid: Fix in 3 Steps

The 30-Second Fix: Reset Statistics

Had a client last month whose entire print queue died because of this—no joke. Their SQL Server started running queries 10x slower after a Windows update. The quickest thing to try is updating statistics. When SQL Server thinks the data distribution changed (even if it didn't), it can drop the cached plan and create a bad one.

Run this in your database:

EXEC sp_updatestats;

This forces SQL Server to recalculate the data distribution. It's safe and takes about 30 seconds for a small database. If your query speeds up after this, you're done. The plan cache will rebuild with better stats.

When this helps: After any big data load (like importing 10k rows), or after a SQL Server update. I've seen this fix a query that was scanning 2 million rows instead of using an index.

The 5-Minute Fix: Clear the Plan Cache (Carefully)

If the stats update didn't work, you might need to clear the plan cache itself. But be careful—this removes ALL cached plans for the server, so first-run queries will be slow for a bit. Only do this during low-traffic hours.

DBCC FREEPROCCACHE;

Or if you only want to clear the cache for a specific database:

DBCC FLUSHAUTHCACHE;
DBCC FREESYSTEMCACHE('ALL', 'your_database_name');

I usually do the first command. It's blunt but works. After running this, SQL Server will recompile queries from scratch. Your next query will be a bit slower as it builds a new plan, but after that, it should be fast again.

Real scenario: Last week, a client's nightly ETL job was running 45 minutes instead of 5. I cleared the cache, and the next run was back to 5 minutes. The cached plan had gone stale after a schema change.

When This Fails

If clearing the cache helps for an hour then it slows down again, you've got a different problem. Likely parameter sniffing or a bad index. Move to the advanced fix.

The 15+ Minute Fix: Rebuild Indexes and Tune the Query

If you're still fighting slow queries after resetting stats and clearing the cache, the problem isn't the cache—it's the query or the indexes. Here's the real fix.

Step 1: Rebuild Indexes

Fragmented indexes can cause SQL Server to generate bad plans. Rebuild them:

ALTER INDEX ALL ON YourTableName REBUILD;

Or for all tables in the database:

EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD';

This can take a few minutes on large tables. Do it during maintenance windows. After rebuilding, update stats again.

Step 2: Check for Parameter Sniffing

This is a common culprit. When SQL Server caches a plan for a query with parameters, the plan is built for the first set of parameter values. If those values are unusual (like a date far in the future), the plan is bad for typical values.

Fix it by adding OPTION (RECOMPILE) to the stored procedure or query. This forces a fresh plan each time:

SELECT * FROM Orders
WHERE OrderDate > @SomeDate
OPTION (RECOMPILE);

Warning: This uses more CPU because query recompiles every time. Only use it for queries that run rarely or have very different parameter values.

Step 3: Manually Force a Good Plan

If nothing else works, you can create a plan guide. This tells SQL Server to use a specific plan you know works well.

First, get the good plan's handle:

SELECT query_plan, plan_handle
FROM sys.dm_exec_query_stats
CROSS APPLY sys.dm_exec_query_plan(plan_handle)
WHERE text LIKE '%your_query_here%';

Then create a plan guide:

EXEC sp_create_plan_guide
    @name = N'Fix_Plan_For_BadQuery',
    @stmt = N'SELECT ... your actual query',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (USE PLAN N''[paste plan XML here]'')';

Honestly, I only do this for mission-critical queries that can't go down. It's a pain.

Bottom Line

Start with the 30-second stats update. If that doesn't work, clear the cache. If that's temporary, rebuild indexes and check for parameter sniffing. Most plan cache issues are just stale stats or a bad parameter sniff. Don't overcomplicate it.