SQL Server Statistics and Cardinality Estimation

The optimizer chooses joins, access methods, and memory grants from estimated row counts. When estimates diverge from reality, a reasonable plan can become expensive.

What to measure

Compare estimated and actual rows at the earliest meaningful operator. Review histogram coverage, modification counters, sampling, ascending keys, correlated predicates, and expressions that hide column values.

Practical approach

Keep automatic statistics enabled, update important statistics when data changes invalidate them, use filtered or multi-column statistics for specific skew, and rewrite predicates that hide distributions.

What to avoid

Do not update every statistic with fullscan nightly, assume an index rebuild updates all statistics, or mask every estimation error with a hint.

Operational result

Statistics maintenance should follow data change and workload sensitivity, not a universal calendar.

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.