Eine Abfrage, die letztes Jahr Millisekunden gedauert hat, kann heute Minuten dauern, einfach weil die Tabelle gewachsen ist. Bei der SQL-Abfrageoptimierung geht es weniger um clevere Tricks als vielmehr um einen wiederholbaren Prozess: Finden Sie heraus, was die Datenbank tut, entfernen Sie die verschwendete Arbeit und überprüfen Sie, ob es geholfen hat.

Wir haben jede der folgenden Techniken an einer Million generierten Zeilen in SQLite 3.50 getestet. Die Timings sind die besten Ergebnisse aus mehreren Läufen auf einem Laptop unter Verwendung einer In-Memory-Datenbank. Sie passen nicht zu Ihrem System, und PostgreSQL, MySQL und SQL Server verfügen jeweils über eigene Optimierer und Planformate. Konzentrieren Sie sich auf den Umfang jeder Verbesserung und auf die dahinter stehenden Prinzipien.

Ergebnisse auf einen Blick

Der Testaufbau

CREATE TABLE customers (
  id INTEGER PRIMARY KEY, name TEXT, city TEXT
);
CREATE TABLE orders (
  id INTEGER PRIMARY KEY, customer_id INT, status TEXT,
  created TEXT, total INT, note TEXT
);
-- 50,000 customers and 1,000,000 orders with random values

Ein einfacher Optimierungsprozess

1. Finden Sie die Abfragen, die wichtig sind. Verwenden Sie langsame Abfrageprotokolle oder Überwachung. Eine 200-ms-Abfrage, die tausendmal pro Minute ausgeführt wird, kann wichtiger sein als ein 10-sekündiger monatlicher Bericht.
2. Lesen Sie den Plan. Sehen Sie, was die Datenbank wirklich tut.
3. Ändern Sie eine Sache. Fügen Sie einen Index hinzu oder schreiben Sie einen Teil der Abfrage neu.
4. Machen Sie erneut, anhand realistischer Daten. Ein Plan mit 100 Testzeilen sagt sehr wenig über eine Million aus.
5. Beobachten Sie es im Laufe der Zeit. Pläne können sich ändern, wenn die Daten wachsen und sich Statistiken ändern.

Lesen Sie einen Ausführungsplan

Ein Ausführungsplan ist die schrittweise Strategie der Datenbank zum Ausführen einer Abfrage, einschließlich der verwendeten Indizes und der Reihenfolge, in der Tabellen verknüpft werden. Stellen Sie eine Abfrage voran, um sie anzuzeigen:

Beachten Sie, dass EXPLAIN ANALYZE in PostgreSQL die Abfrage tatsächlich ausführt. Seien Sie also vorsichtig, wenn Sie es mit UPDATE oder DELETE verwenden. Hier ist, worauf Sie zuerst achten sollten:

Ein vollständiger Scan ist nicht automatisch schlecht. Wenn eine Abfrage den größten Teil einer kleinen Tabelle benötigt, kann das Scannen die schnellste Wahl sein. Vergleichen Sie in PostgreSQLs EXPLAIN ANALYZE auch geschätzte Zeilen mit tatsächlichen Zeilen. Ein großer Unterschied bedeutet oft, dass Tabellenstatistiken veraltet sind.

Fügen Sie den richtigen Index hinzu

Diese Abfrage findet die Bestellungen eines Kunden:

SELECT id, total FROM orders WHERE customer_id = 123;

Vor dem Hinzufügen eines Index war ein vollständiger Scan geplant:

SCAN orders
-- 20 rows in 73 ms

Dann haben wir der Filterspalte einen Index hinzugefügt:

CREATE INDEX idx_orders_customer ON orders(customer_id);

SEARCH orders USING INDEX idx_orders_customer (customer_id=?)
-- 20 rows in 0.01 ms

Die gleichen 20 Zeilen kamen tausendmal schneller zurück, da die Datenbank nicht mehr eine Million Zeilen las, um sie zu finden. Keine andere Technik in diesem Artikel hat uns einen größeren Gewinn beschert. Gute erste Kandidaten sind Spalten, die in WHERE, JOIN und ORDER BY verwendet werden, insbesondere wenn sie die Ergebnisse auf wenige Zeilen eingrenzen. Unser Leitfaden zu SQL-Indizes erklärt, wie sie funktionieren.

Wickeln Sie indizierte Spalten nicht in Funktionen ein

Hier sind zwei Möglichkeiten, März-Bestellungen zu finden, mit einem Index auf created:

-- Function on the column
SELECT id FROM orders WHERE substr(created, 1, 7) = '2026-03';
-- SCAN orders USING COVERING INDEX idx_orders_created
-- 84,961 rows in 96 ms

-- Plain range
SELECT id FROM orders
WHERE created >= '2026-03-01' AND created < '2026-04-01';
-- SEARCH orders USING COVERING INDEX idx_orders_created (created>? AND created<?)
-- 84,961 rows in 33 ms

Beide geben identische Zeilen zurück, die erste dauerte jedoch etwa dreimal so lange. Der Plan zeigt, warum: Mit einer Funktion auf der Spalte kann die Datenbank nicht zu einer Position im sortierten Index springen, also muss sie jeden Eintrag mit SCAN durchlaufen. Die Range-Version kann SEARCH direkt an der richtigen Stelle sein. Eine Bedingung, die einen Index auf diese Weise verwenden kann, heißt sargable.

Das gleiche Problem tritt bei diesen häufigen Mustern auf:

Letzteres haben wir auch überprüft. Ein führender Platzhalter erzeugte SCAN customers, da ein nach dem ersten Buchstaben sortierter Index bei einer Übereinstimmung am Ende nicht weiterhelfen kann.

Zusammengesetzte Indizes

Wenn eine Abfrage nach zwei Spalten filtert, erledigt ein einspaltiger Index nur einen Teil der Aufgabe:

SELECT id FROM orders
WHERE status = 'paid'
  AND created >= '2026-03-01' AND created < '2026-03-08';

-- Using only the created index: 6,198 rows in 19 ms

CREATE INDEX idx_status_created ON orders(status, created);

-- SEARCH orders USING COVERING INDEX idx_status_created
--   (status=? AND created>? AND created<?)
-- 6,198 rows in 2.2 ms

Die Reihenfolge der Spalten ist sehr wichtig. Ein Index zu (status, created) funktioniert wie ein Telefonbuch, sortiert nach Nachname und dann Vorname. Sie können nur einen Nachnamen nachschlagen, nicht jedoch nur einen Vornamen. Allein unsere Abfrage zu status könnte diesen Index verwenden. Das alleinige Filtern nach created konnte es im Allgemeinen nicht effizient nutzen. Als Faustregel gilt, dass die auf Gleichheit getesteten Spalten zuerst und die Bereichsspalten danach platziert werden sollen.

In diesem Plan steht auch, dass der Index den Index abdeckt, was bedeutet, dass der Index alles enthielt, was die Abfrage benötigte, sodass die Tabelle selbst nicht gelesen werden musste. Wenn Sie nur die Spalten auswählen, die Sie benötigen, ist dies wahrscheinlicher, was ein weiterer Grund ist, SELECT * zu vermeiden.

Schnellere Paginierung

Die Verwendung von OFFSET für tiefe Seiten ist mit versteckten Kosten verbunden, da die Datenbank immer noch alle übersprungenen Zeilen durchlaufen muss:

-- Page deep into the results
SELECT id FROM orders ORDER BY id LIMIT 20 OFFSET 500000;
-- 8.1 ms

-- Keyset pagination: continue from the last id seen
SELECT id FROM orders WHERE id > 500000 ORDER BY id LIMIT 20;
-- 0.01 ms

Die Keyset-Paginierung bleibt schnell, egal wie tief Sie gehen. Außerdem wird vermieden, dass Zeilen zwischen den Seiten verschoben werden, wenn neue Daten hinzugefügt werden. Der Nachteil besteht darin, dass Benutzer nicht direkt zu Seite 5.000 springen können, was selten wirklich erforderlich ist. Bei Tabellen mit breiten Zeilen oder mit mehr zu überspringenden Zeilen kann die Lücke viel größer sein als in unserem Test.

Schreiben Sie schlankere Abfragen

• Wählen Sie nur die Spalten aus, die Sie benötigen. SELECT * sendet mehr Daten und kann verhindern, dass ein Index die Abfrage abdeckt.
• Frühzeitig filtern. Verwenden Sie WHERE, um Zeilen vor dem Gruppieren zu entfernen, und HAVING nur für Bedingungen für Aggregate. Siehe SQL GROUP BY und HAVING.
• Verwenden Sie LIMIT, wenn Sie nur wenige Zeilen benötigen.
• Bevorzugen Sie UNION ALL, wenn Duplikate nicht entfernt werden müssen. Unser UNION vs. UNION ALL-Test zeigt, was das spart.
• Vermeiden Sie unnötiges DISTINCT. Oft wird ein Join ausgeblendet, der zu Duplikaten führt.
• Verwenden Sie EXISTS für Existenzprüfungen. Es kann bei der ersten Übereinstimmung aufhören, wie unser Leitfaden zu SQL-Unterabfragen erklärt.
• Achten Sie auf N+1 Abfragen. Eine Abfrage pro Zeile in einer Schleife, die normalerweise durch Anwendungscode verursacht wird, ist oft das eigentliche Problem. Ein einzelner Join oder eine Batch-Abfrage kann Hunderte von Roundtrips ersetzen.

Tritt bei

Indizieren Sie die Spalten, denen Sie beitreten. Wir haben einen Gesamtausgabenbericht für Kunden in einer Stadt erstellt und der Plan entsprach genau Ihren Erwartungen:

SELECT c.name, SUM(o.total)
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE c.city = 'Goa'
GROUP BY c.id;

-- SCAN c
-- SEARCH o USING COVERING INDEX idx_cover (customer_id=?)
-- 9,900 rows in 34 ms

Es scannt die Kunden und verwendet dann einen Index, um die Bestellungen jedes einzelnen Kunden zu finden. Ohne einen Index auf orders.customer_id müsste die Datenbank für jeden Kunden viel mehr Arbeit leisten. Ein Index für den Fremdschlüssel ist eine der häufigsten und wertvollsten Ergänzungen, die Sie vornehmen können. Um Ihr Verständnis der Grundlagen aufzufrischen, lesen Sie die Erklärung von SQL-Joins.

Wenn Indizes Sie kosten

Indizes sind nicht kostenlos, also fügen Sie nicht für jede Spalte einen hinzu:

• Langsamere Schreibvorgänge. Bei jedem Einfügen, Aktualisieren und Löschen muss auch jeder Index aktualisiert werden.
• Mehr Speicherplatz und Arbeitsspeicher. Indizes können auf großen Tabellen groß werden.
• Geringe Vorteile bei nicht selektiven Spalten. Ein Index für eine wahre oder falsche Spalte hilft möglicherweise nicht, wenn die meisten Zeilen übereinstimmen.
• Redundanz. Ein Index auf (a) ist oft unnötig, wenn Sie bereits einen auf (a, b) haben.

Überprüfen Sie regelmäßig die Nutzungsstatistiken und entfernen Sie Indizes, die nicht verwendet werden. Und halten Sie die Statistiken mit ANALYZE oder dem Äquivalent Ihrer Datenbank auf dem neuesten Stand, da der Optimierer bei der Auswahl eines guten Plans darauf angewiesen ist. Manchmal ist der langsame Teil eher der Konflikt als die Abfrage. Lang laufende Transaktionen mit Sperren können dazu führen, dass eine schnelle Abfrage langsam erscheint.

Häufige Fehler

• Optimieren ohne zu messen. Viele sichere Vermutungen erweisen sich als falsch.
• Testen mit winzigen Daten. Pläne und Zeitpläne ändern sich dramatisch, wenn die Tabellen wachsen.
• Einem Tipp für eine andere Datenbank vertrauen. Ratschläge für eine Engine gelten möglicherweise nicht für eine andere.
• Indizes blind hinzufügen. Jeder einzelne verlangsamt die Schreibvorgänge.
• Der Erstdurchlaufeffekt wird ignoriert. Caches machen einen zweiten Durchlauf schneller, also mehrmals ausführen.

Fazit

Die meisten langsamen Abfragen haben gewöhnliche Ursachen: ein fehlender Index, eine Funktion für eine Spalte oder zu viele abgerufene Daten. Nehmen Sie Ihre langsamste echte Abfrage dieser Woche, führen Sie EXPLAIN darauf aus und suchen Sie nach einem vollständigen Scan für eine große Tabelle. Reparieren Sie eine Sache, messen Sie erneut und machen Sie sich Notizen darüber, was Sie geändert haben.

Häufige Fragen

Lerne weiter