The Query Store, introduced in SQL Server 2016, is a built-in feature that captures a history of query execution plans and their runtime statistics inside the database — so you can spot plan regressions and force a known-good plan for a query without changing application code.
Think of it as a flight recorder for query performance: when a query suddenly slows down because its plan changed, the Query Store shows you the old plan and lets you force it back.
Execution plans drift over time as statistics, schemas, and indexes change — and sometimes they drift for the worse. The Query Store is SQL Server's built-in answer to "this query was fast last week; what changed?"
What the Query Store captures
Unlike external monitoring that needs separate setup, the Query Store is built into the database engine. Once enabled, it records, per query: the execution plans the optimizer has used over time, and the runtime statistics for each (duration, CPU, reads, executions). That history is what makes it possible to compare "before" and "after" a plan changed.
Why plans regress
A query's plan is not fixed — it evolves. Statistics updates, schema changes, and index creation or removal can all cause the optimizer to compile a different plan, and occasionally the new plan is worse. These regressions are notoriously time-consuming to diagnose without a record of what the plan used to be. The Query Store keeps that record.
Plan forcing
Because the Query Store retains multiple plans per query, you can tell the optimizer to use a specific one — plan forcing. Per Microsoft, it works through a mechanism similar to a query hint but requires no change to the application. When a regression hits, forcing the previously known-good plan can resolve it in minutes rather than hours.
Automatic Plan Correction
From SQL Server 2017, Automatic Plan Correction (APC) builds on the Query Store: it monitors plans, detects when a new plan performs significantly worse than a previous known-good one, and automatically forces the good plan back — no DBA intervention required. Notably, it keeps checking, and will automatically unforce the plan if forcing turns out not to help.
Plan forcing is one way to stabilize a parameter-sniffing problem once you have found a good plan — it pins that plan in place.
Query Store vs. optimizing the procedure
To be precise about scope: the Query Store and plan forcing are native SQL Server features for plan stability — they make a query keep using a good plan. They do not change the procedure's T-SQL or its indexes. SprocOptimizer works at a different layer: it analyzes a procedure and proposes a rewrite or index change, then verifies logical equivalence and validates the result before promotion. The two are complementary — the Query Store stabilizes the plan a query gets; optimization changes the query so a better plan is possible in the first place.
Frequently asked questions
The Query Store, introduced in SQL Server 2016, is a built-in feature that captures a history of query execution plans and their runtime statistics inside the database. Because it is built into the engine, it gives you a flight recorder of query performance over time without any external tooling, which makes regressions easy to spot and investigate.
Plan forcing directs the query processor to use a specific execution plan that the Query Store has retained for a query. It works much like a query hint but requires no change to the application. It is the fastest way to resolve a regression caused by the optimizer switching to a worse plan: force the previously known-good plan back.
Automatic Plan Correction, available from SQL Server 2017, builds on the Query Store: it monitors plans, detects when a new plan performs significantly worse than a previous known-good plan, and automatically forces the good plan back without DBA intervention. It also keeps checking, and will automatically unforce the plan if forcing turns out not to help.
The Query Store was introduced in SQL Server 2016. Automatic Plan Correction, which uses Query Store data to automatically force a last-known-good plan after a regression, was added in SQL Server 2017.
Primary sources & further reading
- Microsoft Learn — Monitor performance by using the Query Store.
- Microsoft Learn — Query Store usage scenarios.
- SQLPerformance.com — Automatic Plan Correction in SQL Server.
Beyond forcing a plan — fix the query
SprocOptimizer analyzes the procedure itself and validates a better rewrite, complementing native plan stability — on-premises, with no row-level data leaving your network.
Request a Demo Read the Optimization Guide