Use Query Store as a SQL Server Performance Flight Recorder

Many performance incidents disappear before an engineer captures the plan. Query Store preserves query, plan, runtime, and wait history for later analysis.

What to measure

Compare duration, CPU, logical reads, executions, waits, and plans over the exact incident window. Determine whether regression followed deployment, statistics changes, or a new parameter-sensitive plan.

Practical approach

Configure an intentional size and cleanup policy. Preserve both the regressed and previous plans. Use a Query Store hint or forced plan only as controlled stabilization with monitoring and an expiration condition.

What to avoid

Do not force the first plan that looks fast, ignore a read-only Query Store, or leave emergency hints in place forever.

Operational result

Query Store turns a vague report that the database was slow into a time-bounded investigation supported by evidence.

Production checklist

Capture a baseline and define the expected improvement. Test with representative data and concurrency. Preserve the original setting or plan, prepare a rollback, deploy during an appropriate window, and monitor the next normal workload peak.

If you want help applying this method to a specific SQL Server environment, use the question form below and include the SQL Server version, database size, workload pattern, and evidence already collected.