Stale statistics and plans that used to be fine
How out-of-date statistics create sudden regressions after data growth, ETL loads, and “nothing changed” releases.
Users say nothing changed. The data did. Statistics did not keep up. Plans went sideways.
Classic story
- Nightly load inserts millions of rows
- Auto-update thresholds do not fire the way the team expects on large tables
- Cardinality estimates stay stuck in the past
- A seek becomes a scan — or a parallel monster appears
- Someone reboots “to fix SQL”
Health-check signals
- Critical tables with very old stats relative to modification counters
- Heavy ETL without a stats strategy
- Over-reliance on “rebuild indexes nightly” as the only stats plan
- No Query Store to show plan regressions
Sustainable practice
- Identify tables where stale stats hurt most
- Schedule updates after large loads
- Consider sample rates for huge tables
- Use Query Store to catch plan flips
- Separate stats strategy from blind index rebuild religion
Why this belongs in a free check
Stats health is visible quickly and often explains intermittent pain better than buying hardware. It is a high-value conversation starter for performance work.
Need hands-on SQL Server help?
Allay Data Solutions offers maintenance, tuning, and assessments from Port Elizabeth, South Africa.