A useful first question is not “Which index should we add?” but “Which workload changed, and when?” SQL Server Query Store retains query, plan, and runtime-statistics history, helping teams compare plan and performance changes over time.[1]
A low-risk investigation checklist
- Define the complaint. Identify the user workflow, query or application path, time window, and what “slow” means to the team.
- Compare like with like. Examine the same query and comparable time periods; note execution frequency and workload conditions.
- Check for a plan change. Query Store keeps multiple plans for a query, which can help identify regressions associated with plan changes.[1]
- Look beyond the plan. Consider changes to statistics, schema, indexes, data volume, application behavior, and workload concurrency. These are possible investigation paths, not assumed causes.
- Choose the smallest safe next step. Validate a proposed change in an appropriate environment, preserve a rollback path, and compare the same measurements afterward. Plan forcing or index changes should follow technical review, not a generic checklist.
Capture these observations
| Field | Record |
|---|---|
| Workflow / query identifier | |
| User-visible symptom and time window | |
| Baseline measure and its source | |
| Query Store plan/runtime evidence available? | |
| Recent changes or competing explanations | |
| Proposed next check (hypothesis) | |
| Test environment, risk, and rollback |
This is a practical triage aid, not a diagnosis or promise of performance gains. Query Store availability, configuration, and retention should be checked against the relevant SQL Server version and operational policies.
ADI supports data engineering, SQL Server optimization, Power BI reporting, and practical AI workflow automation. Engagement scope and terms are agreed case by case; no outcome is guaranteed.
Source
- Microsoft Learn, “Monitor Performance by Using the Query Store - SQL Server” (accessed 20 October 2026).