Azure SQL Query Store uses database Query Store data to review query history, plan changes, and resource usage over time.
What You Can Review
- Top resource queries in a time window.
- Plan buckets and plan changes.
- Query Store properties.
- Execution plans where available, including operator drill-down and AI plan review.
Workflow
- Open Query Store for the Azure SQL database.
- Select the time window.
- Review top resource queries.
- Open plan buckets for a query.
- Load plan detail where available and review Azure SQL Execution Plans.
- Compare findings with Queries, Waits, and Indexes.
Why Query Store Is Central For Azure SQL
Azure SQL enables many monitoring decisions through Query Store. It helps show whether a query changed plans, regressed after a release, became expensive during a specific time window, or was affected by parameter-sensitive behavior. Query Store is also useful when the slow query is no longer running by the time you open Activity.
Use Query Store alongside service tier and elastic pool data. A query regression may be a plan issue, but it may also coincide with pool pressure, storage limits, or a workload spike.
If a query has multiple plans, use plan buckets to identify the plan tied to the problem window. Then open the execution plan and inspect expensive operators, warnings, parameters, and missing index evidence before deciding whether to tune SQL or adjust Azure capacity.
Azure SQL Query Store FAQ
Is Query Store database scoped?
Yes. Query Store belongs to each Azure SQL database. Open the database-level Query Store page for the most accurate scope.
Why are some plans missing?
Plans may be unavailable if Query Store is disabled, cleanup removed old data, the query is outside the selected time range, or permissions are incomplete.
Can Query Store prove a fix worked?
It can provide before and after metrics for duration, CPU, reads, writes, and plan choice. Pair that evidence with user-facing performance checks.
Next Steps From Query Store
After identifying a query in Query Store, compare runtime history with the incident or release window. If a plan changed, preserve the query identifier, time range, and plan evidence before proposing a fix. Then review Indexes, Waits, and Activity to confirm whether the issue is plan quality, resource pressure, blocking, or workload growth.