Du lieferst das Feature aus, auf deinem Laptop funktioniert es, und dann braucht ein Endpoint in Produktion drei Sekunden. Du weißt schon, dass eine Query schuld ist. Was du nicht weißt: welcher Teil davon. Und das Tool, das es dir sagen soll, liefert eine Wand aus eingerücktem Text mit Zahlen, bei denen du die Augen zusammenkneifen musst.
Diese Textwand ist ein EXPLAIN-Plan, und sie enthält die ganze Antwort. Die Datenbank sagt dir genau, wie sie deine Query ausführen wird, Knoten für Knoten, mit Kosten an jedem einzelnen. Das Problem ist das Format. Ein roher Plan ist dicht, tief verschachtelt und für einen Parser optimiert, nicht für einen Menschen, der ihn freitags um 16 Uhr liest. Also suchen die meisten von uns nach dem Wort "Seq Scan", spüren ein vages Unbehagen und machen weiter.
Den Ausführungsplan lesen: ein Baum, der sich als Text ausgibt
Jeder EXPLAIN-Plan ist in Wirklichkeit ein Baum. Die Wurzel ist das Endergebnis, ihre Kinder sind die Schritte, die es speisen, und jeder Schritt trägt geschätzte Kosten. Wenn du ihn als Text ausgibst, wird diese Struktur zu Einrückung plattgedrückt, und das Einzige, was dich wirklich interessiert (wohin die Zeit geht), verschwindet zwischen Zeilen, Breiten und Schleifenzählern.
Die Lösung: Hör auf, den Baum als Text zu lesen, und fang an, ihn als Baum zu sehen. Fordere zuerst die maschinenfreundliche Form an:
-- Postgres: ask for JSON so the plan keeps its structure EXPLAIN (ANALYZE, FORMAT JSON) SELECT u.name, count(o.id) FROM users u JOIN orders o ON o.user_id = u.id WHERE o.created_at > '2026-01-01' GROUP BY u.name;
Postgres (und MySQL, mit seinem eigenen FORMAT=JSON) antwortet dann mit einem JSON-Dokument statt des üblichen Textes. Es sieht so aus, und ehrlich gesagt ist es von Hand kaum angenehmer zu lesen:
[{ "Plan": {
"Node Type": "Hash Join",
"Total Cost": 18422.6,
"Plans": [
{ "Node Type": "Seq Scan",
"Relation Name": "orders",
"Total Cost": 15903.0 },
{ "Node Type": "Index Scan",
"Relation Name": "users",
"Total Cost": 211.4 }
] } }]
Einfügen, und der langsame Teil leuchtet auf
Kopiere dieses JSON, öffne in LetDraw den Dialog Aus Code generieren und füge es ein. Du musst nicht sagen, was es ist. LetDraw erkennt einen Postgres- oder MySQL-EXPLAIN-Plan automatisch und stellt ihn als Plan-Baum mit Heatmap dar: den echten Baum, gezeichnet, und jeder Knoten nach seinen Kosten eingefärbt.
Der teuerste Knoten ist der röteste. Das ist das ganze Review, auf einen Blick.
Heiße Knoten glühen rot und orange; günstige bleiben grün. Statt Kosten mit dem Auge zu parsen, schaust du auf das Bild, und deine Aufmerksamkeit geht direkt zum Engpass.
orders erledigt fast die ganze Arbeit; die users-Seite ist bereits indiziert.Jetzt ist die Diagnose offensichtlich. Die orders-Seite ist ein Seq Scan, ein vollständiges Lesen der Tabelle, während users bereits über einen Index Scan bedient wird. Der teure Hash Join ganz oben ist teuer, weil er von diesem vollständigen Scan gespeist wird. Den fehlenden Index auf orders(created_at) hast du nicht aus einer Kostenspalte abgeleitet; er ist der eine rote Kasten auf der Seite.
Deine Query verlässt nie den Browser
Danach fragen Datenbankleute meist als Erstes. Ein EXPLAIN-Plan kann Tabellennamen, Spaltennamen und Zeilenschätzungen verraten, die du lieber keinem beliebigen Web-Tool geben willst. LetDraw erledigt das Ganze clientseitig. Parsen und Layout passieren in deinem Browser, auf deinem Rechner. Nichts von deiner Query oder deinem Schema wird auf einen Server hochgeladen, um das Bild zu erzeugen.
- Füge einen Plan aus einer Produktionsdatenbank ein, ohne dass er deinen Laptop verlässt
- Kein Konto und kein Upload nötig, um einen Plan als Baum darzustellen
- Derselbe Datenschutz gilt, ob du die gehostete App nutzt oder sie selbst hostest
EXPLAIN (ANALYZE), wenn du es dir leisten kannst, die Query tatsächlich auszuführen. Aus den Kosten werden gemessene Zeiten statt Schätzungen, und die Heatmap zeigt, wohin die Zeit wirklich ging, nicht nur, wohin der Planner sie vermutet hat.Es ist ein Diagramm, also kannst du damit arbeiten
Der Plan-Baum ist kein statisches Bild. Er besteht aus denselben editierbaren Formen wie alles andere in LetDraw, du kannst also in dem Moment, in dem du das Problem entdeckst, daraus etwas machen, das ein Teammitglied versteht.
- Kreise den heißen Pfad ein und setz eine Notiz zum fehlenden Index daneben
- Füge den Plan vorher und nachher nebeneinander ein, um zu zeigen, dass der Fix gewirkt hat
- Exportiere als PNG, SVG oder PDF und hänge es an den Pull Request oder den Incident-Bericht
Einen rohen Plan entziffert ein Engineer allein. Einen Baum mit Heatmap und einer Notiz am roten Kasten versteht das ganze Review in wenigen Sekunden. Das ist der Unterschied zwischen "die Query ist langsam" und "hier ist der langsame Teil, und hier ist der einzeilige Fix". Füge deinen nächsten EXPLAIN-Plan ein und lass den Engpass sich selbst vorstellen.