Ändert die DB bei unverändertem Code die Art, wie sie dieselbe Query abarbeitet (Ausführungsplan), dauert eine Query, die gestern 2 ms brauchte, heute mehrere hundert ms.
Warum Automatische Statistikaktualisierung, DB-Neustart oder veränderte Datenverteilung lassen die DB den Ausführungsplan neu erstellen → Folge Ein Plan ohne Index wird gewählt, dieselbe Query wird um einen zwei- bis dreistelligen Faktor langsamer und hält Verbindungen belegt → Auf dem Bildschirm Ohne Deployment lädt eine bestimmte Funktion plötzlich langsam, und auch andere Anfragen warten
Queries, deren Ergebnismenge stark vom Parameterwert abhängt, aufteilen oder Plan-Hints prüfen, Queries so gestalten, dass sie zuverlässig einen Index nutzen.
Aufgaben Infrastrukturteam
Slow-Query-Log und Ausführungspläne überwachen, gute Pläne fixieren (z. B. mit dem Query Store von SQL Server), Zeitpunkte der Statistikaktualisierung steuern.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · Durchschnittliche Ausführungszeit je Query
Wo nachsehen
Durchschnittszeiten gleich aufgebauter Queries regelmäßig erfassen und den Verlauf prüfen. MySQL: AVG_TIMER_WAIT in events_statements_summary_by_digest, PostgreSQL: mean_exec_time in pg_stat_statements (bis 12 mean_time). Ausführungspläne vor und nach der Verlangsamung mit EXPLAIN oder PostgreSQL auto_explain vergleichen, bei SQL Server über die Ansicht Regressed Queries im Query Store
Spricht dafür
Zu einem Zeitpunkt ohne Deployment steigt die Durchschnittszeit einer Query stufenartig um einen zweistelligen Faktor, der Zeitpunkt fällt mit Statistikaktualisierung oder DB-Neustart zusammen, und der Ausführungsplan hat sich geändert
Spricht dagegen
Ausführungsplan unverändert, trotzdem langsamer: Datenwachstum, Warten auf Locks (db-hot-row) oder Datenträger
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
SQL Server verwendet einen Plan wieder, der für die zuerst übergebenen Werte erstellt wurde (Parameter Sniffing). Wird ein Plan, der für einen neuen Charakter mit wenigen Items entstand, für einen alten Charakter mit Zehntausenden Items verwendet, wird die Query deutlich langsamer; der umgekehrte Fall ist ebenso häufig. Löscht ein Neustart den Plan, ist zunächst alles in Ordnung, bis es wieder schlechter wird.
Quellen
Query Processing Architecture GuideMicrosoft SQL Server Parameter Sniffing: Der Ausführungsplan wird beim Kompilieren oder Neukompilieren für die übergebenen Parameterwerte erstellt
Parameter Sensitive Plan OptimizationMicrosoft SQL Server Bei ungleichmäßiger Datenverteilung passt ein einzelner gecachter Plan nicht für alle Parameterwerte
Monitor performance by using the Query StoreMicrosoft SQL Server Pläne ändern sich durch Statistik-, Schema- oder Indexänderungen, der Plan-Cache hält nur den neuesten Plan; Plan Forcing im Query Store fixiert gute Pläne, die Ansicht Regressed Queries vergleicht langsamer gewordene Queries und ihre Pläne
Statement Summary TablesMySQL events_statements_summary_by_digest: COUNT_STAR und AVG_TIMER_WAIT (Durchschnittszeit) je Gruppe gleich aufgebauter Queries