In der Tabelle order_events mit rund vier Millionen Zeilen zu E-Commerce-Ereignissen blieb eine Abfrage, die die letzten 30 Tage Aktivität für eine bestimmte customer_id abrufen sollte, während eines nächtlichen Einsatzes hängen. Drei Wochen zuvor war bereits ein Index auf customer_id angelegt worden, doch EXPLAIN ANALYZE zeigte, dass PostgreSQL trotzdem einen sequenziellen Scan über die gesamte Tabelle ausführte. Aus einer erwarteten Laufzeit von 40 Millisekunden wurden etwa vier Sekunden.

order_events query
SELECT * FROM order_events
WHERE customer_id = 8842
AND created_at > now() - interval '30 days'
ORDER BY created_at DESC;

Ursache war eine Diskrepanz zwischen dem Index und der ORDER-BY-Klausel der Abfrage. Der Index deckte nur customer_id ab, sodass PostgreSQL die passenden Zeilen zwar schnell fand, sie danach aber komplett in den Speicher laden und nach created_at sortieren musste. Ein zusammengesetzter Index auf (customer_id, created_at DESC) passte genau zum Zugriffsmuster der Abfrage und senkte die Laufzeit auf neun Millisekunden.

Derselbe Fehler war zuvor schon bei einer Terminplanungs-App im Gesundheitswesen und einem Analyse-Tool für einen Logistikkunden aufgetreten, jeweils weil ein Index nur die WHERE-Klausel abdeckte, während Sortier-, Gruppier- oder Join-Spalten unberücksichtigt blieben. Daraus entstand eine vierstufige Routine für jede langsame Abfrage: EXPLAIN ANALYZE ausführen und auf einen Seq Scan bei Tabellen mit mehr als ein paar tausend Zeilen achten; ORDER BY-, GROUP BY- und JOIN-Spalten prüfen, um zu entscheiden, ob ein zusammengesetzter Index mehreren einzelnen vorzuziehen ist; die Selektivität der Spalten prüfen, da Felder mit wenigen Werten wie ein order_status mit nur drei Zuständen allein kaum helfen und mit einer selektiveren Spalte kombiniert werden sollten; und schließlich die tatsächlichen Millisekunden-Werte aus EXPLAIN ANALYZE vor und nach einer Änderung dokumentieren, statt sich auf ein Gefühl zu verlassen.