Wenn eine Abfrage langsam ist, ist die schlechteste Reaktion, instinktiv zu optimieren.
PostgreSQL sagt Ihnen bereits, wie es die Abfrage ausgeführt hat. Sie müssen nur nachfragen.
Das ist der Zweck von EXPLAIN ANALYZE.
Beginnen Sie mit dem Plan, nicht mit der Theorie
EXPLAIN ANALYZE
SELECT *
FROM users
WHERE status = 'archived';
Dies gibt Ihnen den tatsächlichen Ausführungsplan, nicht nur den SQL-Text, von dem Sie hofften, dass er effizient sein würde.
Die ersten Punkte, auf die man achten sollte
Sie müssen nicht jeden Plan-Knoten am ersten Tag beherrschen. Beginnen Sie mit:
- Scan-Typ: sequenzieller Scan vs. indexgestützter Zugriff
- geschätzte Zeilen vs. tatsächliche Zeilen
- Gesamtdauer der Ausführung
- ob teure Schritte häufig wiederholt werden
Diese Punkte sind oft ausreichend, um die meisten "Warum ist das langsam?" Vorfälle zu erklären.
Ein sequenzieller Scan ist nicht automatisch schlecht
Einer der häufigsten Anfängerfehler ist anzunehmen, dass jeder Seq Scan ein Fehler ist.
Das ist er nicht.
Wenn die Tabelle klein ist oder die Abfrage ohnehin einen großen Prozentsatz der Zeilen benötigt, kann ein sequenzieller Scan der richtige Plan sein.
Die eigentliche Frage ist, ob der gewählte Plan zur Arbeitslast passt.
Was ein Index oft verändert
Wenn ein selektiver Filter keinen nützlichen Index hat, hat PostgreSQL möglicherweise keine kostengünstige Möglichkeit, die Suche einzugrenzen.
Einen Index hinzuzufügen kann das ändern:
CREATE INDEX idx_users_status ON users(status);
Aber auch dann sollten Sie nicht bei "Index hinzugefügt" stehen bleiben. Führen Sie EXPLAIN ANALYZE erneut aus und bestätigen Sie, dass der neue Plan tatsächlich besser ist.
Die wahre Fähigkeit
Das Lesen von Ausführungsplänen geht weniger darum, Knotennamen zu memorieren, sondern mehr darum, zu fragen:
- Wie viele Zeilen dachte PostgreSQL, dass es berühren würde?
- Wie viele hat es tatsächlich berührt?
- Wo wird Zeit aufgewendet?
- Macht der Plan wiederholte Arbeiten?
Das ist der Weg vom Folklore zur Ingenieurskunst.
Weiterführende Literatur