The Query Regression alert identifies MySQL and MariaDB statement digests whose recent workload has worsened against their baseline.
Mini DBA samples Performance Schema statement digests into Query Intelligence history and compares recent interval deltas with the recent baseline. A regression can be raised when execution time, total work, rows examined, disk temporary table use, lock time, errors, warnings, or call volume materially worsens.
This alert points you toward query patterns that have changed, not only queries that are currently visible in a live process list. It helps find newly expensive statements, plan changes, missing indexes, inefficient access patterns, or bursty application behavior.
Enable it after Performance Schema statement digest collection is working and the server has had time to build a normal workload baseline. It is most useful on production OLTP, reporting, and integration workloads where a small number of regressed digests can create broad user-visible pressure.
The default major threshold is 5 regressed queries and the comparison direction is over. Use higher thresholds on batch-heavy or development systems. Use lower thresholds on latency-sensitive production systems, small instances, and workloads with strict recovery or availability commitments.
Open MySQL Query Analysis and review the History tab around the alert time. Check the regressed digest, sample SQL text or normalized digest text, captured plan history, rows examined, temporary table counters, and lock-time evidence. Then compare the query with indexes, table statistics, recent deploys, data growth, and blocking evidence before changing indexes or application SQL.
If the alert is noisy, confirm whether the workload naturally has short bursts or whether Query Intelligence has only just started sampling. Raise the threshold for expected batch windows, but avoid disabling the alert until you know whether the change is a real trend.