.svg)
Article Summary:
Use Query Store history to find regressions, compare execution plans and apply controlled mitigations without losing the evidence.
Query Store gives SQL Server a history of query text, execution plans and runtime behaviour. That makes it particularly useful when a query that was fast yesterday is slow today. The value comes from keeping the history healthy, comparing the right time windows and treating plan forcing as a controlled mitigation rather than a permanent reflex.
Configure capture for the workload
Microsoft's Query Store documentation covers operation mode, capture policy, runtime intervals, retention and maximum size. High-volume estates should avoid collecting low-value ad hoc noise indefinitely. Set a size that reflects workload and history requirements, then alert if Query Store becomes read-only or unhealthy.
Find a regression by time
Start with the business incident window. Compare duration, CPU, logical reads, execution count and plan ID against a known good period. Separate a slower plan from a heavier workload: total resource use can rise because each execution costs more, because calls increased, or both.
- Regressed queries view
- Top resource-consuming queries
- Plan comparison
- Runtime variation by interval
- Query wait statistics where supported
Read plans in context
Review estimated and actual row counts, parameter values, joins, spills, implicit conversions and access methods. Check statistics, indexes, database compatibility and recent schema changes. A new plan may expose a data-distribution issue rather than an optimizer defect.
Force only with an exit plan
If a previous plan is known to be safe, forcing can restore service while analysis continues. Record why it was forced, expected metrics, owner and review date. Monitor for forcing failures and for workloads where the old plan becomes unsuitable.
Prefer a tested query, schema or statistics correction when it addresses the root cause. Query Store hints can also influence behaviour in supported versions, but they need the same governance as code changes.
Keep the store operational
Review growth, cleanup, capture mode and failed forcing as routine database maintenance. Newer engine releases continue to expand Query Store-related capabilities, as summarised in What's new in SQL Server 2025. Test version-specific behaviour before changing estate-wide defaults.
- Alert on actual_state_desc
- Track used storage
- Retain enough history for business cycles
- Document forces and hints
- Back up and recover with the database
Talk to a database specialist
A change to support, licensing, cloud architecture or a production database should be based on evidence from your own estate. Pro DBA can assess the current position, identify the material risks and help you plan the next step. Contact the Pro DBA team to discuss your environment.
