N+1-Abfragen: erkennen durch Zählen und beheben durch Batching

Worum es geht

Code lädt mit einer Abfrage eine Liste von N übergeordneten Zeilen und liest dann bei jeder Zeile eine lazy geladene Beziehung; das ORM stellt pro Zeile eine weitere Abfrage. Die SQLAlchemy-Dokumentation benennt das: Für beliebige N geladene Objekte bedeutet der Zugriff auf deren lazy geladene Attribute, dass N+1 SELECT-Anweisungen ausgeführt werden. Dieselbe Form tritt auch ohne ORM auf: eine Schleife, die je Element eine HTTP-API aufruft, ein GraphQL-Resolver, der je Knoten abruft, ein Cache-Lookup je Schlüssel.

Warum es wichtig ist

Jede Abfrage kostet einen Roundtrip, egal wie wenig sie zurückgibt. Eine Seite mit 200 Zeilen wird zu 201 Roundtrips; die Kosten skalieren mit den Daten, nicht mit dem Code, daher ist das Problem bei Testdaten mit drei Zeilen unsichtbar und tritt erst in der Produktion auf. Auch Slow-Query-Logs zeigen es nicht, weil jede der N Abfragen für sich schnell ist.

So wird es angewendet

• Durch Zählen erkennen. Die Anzahl Abfragen je Anfrage in Tests prüfen (Djangos assertNumQueries, das prüft, dass ein Aufruf eine bestimmte Anzahl Abfragen ausführt; ein Engine-Event-Listener in SQLAlchemy; ein Zähler je Anfrage im Query-Logger) und scheitern lassen, wenn die Anzahl von der Ergebnisgrösse abhängt: dieselbe Anfrage mit 1 Zeile und mit 50 Zeilen ausführen und vergleichen.
• Unerwünschte Lazy Loads laut scheitern lassen. SQLAlchemys raiseload() ersetzt Lazy Loading durch eine Ausnahme, sodass ein neuer Attributzugriff in einem Template oder Serializer in Tests auffällt statt erst als N+1 in der Produktion.
• To-one-Beziehungen mit einem Join beheben: select_related() in Django, joinedload() in SQLAlchemy. Eine Abfrage, breitere Zeilen.
• Sammlungen mit einer zweiten, über IN (ids) geschlüsselten Abfrage beheben: prefetch_related() in Django, selectinload() in SQLAlchemy, das dessen Dokumentation gegenüber dem älteren Subquery-Loading bevorzugt. Zwei Abfragen statt N+1, keine Zeilenvervielfachung.
• Ausserhalb von ORMs dieselbe Idee anwenden: zuerst die Schlüssel sammeln, sie in einem Aufruf abrufen, dann die Ergebnisse den Elementen zuordnen (das DataLoader-Muster); bei entfernten APIs Batch-Endpunkte oder begrenzte Nebenläufigkeit verwenden.
• Der Django-Optimierungsleitfaden empfiehlt zu verstehen, wann Querysets ausgewertet werden und welche Attribute gecacht sind, und select_related() und prefetch_related() dort anzuwenden, wo nötig, gegebenenfalls in Managern, mit dem Vorbehalt, dass der Zugriff auf verknüpfte Objekte den Basis-Manager statt den Standard-Manager verwendet.

Stolpersteine

Eine Sammlung zu joinen wiederholt die übergeordnete Zeile je Kind und kann langsamer sein als zwei Abfragen. Alles vorab zu laden verschwendet Speicher für Felder, die niemand liest. Eine IN-Liste mit Zehntausenden IDs braucht Chunking. Die Anzahl der Abfragen ist eine Eigenschaft des Codepfads, nicht des Modells: Ein zusätzliches Attribut in einem Serializer führt N+1 wieder ein, weshalb die Zählprüfung dauerhaft in die Test-Suite gehört.