Profiler und Prozessliste
Zwei Werkzeuge für die Frage „warum ist das langsam?" — eines schaut auf die Abfrage, das andere auf den Server.
Abfrage-Profiler
Klicken Sie Profiler in der Werkzeugleiste oder den Knopf Explain im SQL-Editor, um die Anweisung, an der Sie gerade arbeiten, direkt dorthin zu schicken. Sie können auch Verbindung und Datenbank wählen und eine Abfrage einfügen.
Der Plan kommt als Graph zurück: ein Kasten je Operation, verbunden mit den Eingaben, aus denen er zieht — ein Join liest sich also als ein Knoten, der aus zwei Tabellen schöpft, statt als Einrückung. Jeder Kasten trägt Tabelle, Zugriffsart, Zeilenzahlen und Kosten, mit einem farbigen Streifen, der ihn gegen den teuersten Knoten des Plans gewichtet. Ein Klick auf einen Kasten öffnet die vollen Angaben: Bedingungen, Indexnamen, Puffer-Zähler.
Derselbe Plan steht auch als Baum und als Rohausgabe des Servers zur Verfügung.
Geschätzt oder gemessen
Eine Markierung über dem Plan sagt, was Sie vor sich haben:
- Geschätzt — die Annahme des Planers. Es wurde nichts ausgeführt.
- Gemessen — die Abfrage lief wirklich, und die Kästen zeigen die tatsächlichen Zeilen neben den Schätzungen.
Das Häkchen ANALYZE fordert einen gemessenen Plan an. Ob Sie einen bekommen, hängt vom Server ab, und NabuSQL nennt, worauf es sich einlassen musste, statt stillschweigend abzustufen:
| System | Gemessene Pläne |
|---|---|
| MySQL 8.3+ | Ja, mit vollem Graph |
| MariaDB 10.1+ | Ja, mit vollem Graph |
| MySQL 8.0.18+ | Ja, aber der Server liefert nur Text — kein Graph |
| Ältere MySQL / MariaDB | Nein — Sie bekommen die Schätzung, klar gekennzeichnet |
| PostgreSQL | Ja, mit Puffer-Zählern |
| SQLite | Einen Ausführungsplan gibt es nicht |
SQL Server
SQL Server liefert einen tabellarischen Schätzplan statt eines Graphen. Seinen echten Plan zu lesen erfordert SHOWPLAN_XML, das NabuSQL noch nicht auswertet — die Seite sagt das, statt einen Graphen vorzutäuschen.
Einen Plan lesen
Knoten, die einen zweiten Blick verdienen, sind mit ⚠ markiert:
- Vollständiger Tabellenscan — die ganze Tabelle wird gelesen, wo Sie einen Indexzugriff erwartet hätten.
- Geringe Selektivität — ein Index wurde genutzt, hat aber kaum etwas eingegrenzt.
- Schätzung weit daneben — der Planer erwartete eine um eine Größenordnung andere Zeilenzahl. Meist veraltete Statistiken, und der Grund für die gewählte Planform. Führen Sie ANALYZE auf der Tabelle aus und versuchen Sie es erneut.
Ebenfalls beachtenswert: Kosten, die sich auf einen Knoten konzentrieren — dort wird zuerst optimiert — und ein Index, der existiert, aber nicht genutzt wird, meist weil die WHERE-Klausel die Spalte in eine Funktion packt oder sie mit einem anderen Typ vergleicht.
Nachdem Sie unter Tabellen und Spalten einen Index angelegt haben, lassen Sie den Profiler erneut laufen und bestätigen, dass sich der Plan tatsächlich geändert hat. Ein Index, den der Planer ignoriert, kostet Sie Schreibleistung und bringt nichts.
Prozessliste
Rechtsklick auf eine Datenbank und Process List zeigt, was der Server gerade tut: die verbundenen Sitzungen, die laufenden Abfragen und wie lange sie schon laufen.
Kill beendet eine Sitzung. Das ist das Werkzeug für die entlaufene Abfrage, die Sperren hält, während der Rest der Anwendung wartet.
Eine Sitzung zu beenden bedeutet ein Rollback
Eine unterbrochene Transaktion wird vom Server zurückgerollt, was bei einem langen Schreibvorgang so lange dauern kann wie die Anweisung selbst. Sehen Sie nach, was die Sitzung tut, bevor Sie sie beenden.
Eine praktische Reihenfolge
- Die Anwendung ist langsam → Prozessliste: blockiert eine Abfrage alles andere?
- Eine bestimmte Abfrage ist langsam → Profiler: wo liegen ihre Kosten?
- Korrektur — Index, umgeschriebenes
WHERE, andere Join-Reihenfolge. - Profiler erneut laufen lassen und bestätigen, dass der Plan sich geändert hat.