Query Plan Regression
A sudden latency increase caused by the database optimiser choosing a different execution plan for an unchanged query, typically after statistics or data volume change.
The signature is distinctive: a query that was fast for months becomes slow with no code deployment. Because nothing changed in the application, investigation often looks in the wrong places for hours.
The cause is that the optimiser chooses plans from statistics about data distribution. When those statistics are stale, or when growth crosses a threshold, the estimated cost of two plans flips and it switches — from an index seek to a full scan, or from a nested loop to a hash join.
Diagnosis: capture the actual execution plan and compare estimated against actual row counts. A large divergence means stale or insufficient statistics, and is the most common finding.
Remedies in order: refresh statistics and consider more frequent automatic updates; increase the histogram resolution for skewed columns; restructure the query so the estimate is easier; and only as a last resort, pin a plan or add an optimiser hint — which freezes today's decision and becomes wrong when the data changes again.
Prevention is monitoring: track per-query latency and plan changes, so the regression is detected as an event with a cause rather than as a mysterious slowdown.