Skip to content

SQL Server slow queries

Investigate a regression before choosing a fix.

The problem

A query that was fast yesterday can become slow after a plan, statistics, workload or data distribution change. Aggregate CPU alone does not identify the affected statement.

Recognise the symptoms

  • Higher duration or CPU for a known query
  • More logical reads after a deployment
  • Response time varies between executions

A practical investigation workflow

  1. Define the regression window

    Record the query, affected database, time window and representative parameters. Compare like-for-like workload periods.

  2. Compare historical evidence

    Where enabled and available, use Query Store to compare plans and runtime statistics. Check waits, reads and execution counts alongside duration.

  3. Test the likely cause

    Review estimates, statistics, indexes and parameter sensitivity. Reproduce in a suitable test environment before choosing a change.

  4. Measure the result

    Compare duration, CPU and reads, and watch related queries for unintended effects. Record a rollback plan.

What success looks like

A performance change justified by evidence and a repeatable before-and-after comparison.

Query Store availability and captured history vary by version and configuration. Plan forcing is a reviewed mitigation, not a universal fix.

Microsoft: monitor performance with Query Store

Related workflows

SQL Server Job MonitoringDiscuss your DBA workflow