Eine N+1-Abfrage ist ein Antimuster beim Datenbankzugriff: Die Anwendung lädt mit einer Abfrage eine Liste von N Datensätzen und führt anschließend N weitere Abfragen aus, eine pro Datensatz, um zugehörige Daten zu laden. Meist entsteht das durch Lazy Loading in ORMs und macht aus einem Roundtrip Hunderte, was Latenz und Datenbanklast vervielfacht.
Was das N+1-Problem ist
Das N+1-Problem tritt auf, wenn Code eine Sammlung lädt und dann in einer Schleife auf eine Relation jedes Elements zugreift. Nehmen wir eine Bestellübersicht mit 50 Bestellungen samt Kundennamen. Die Anwendung führt zuerst eine Abfrage für die Bestellungen aus und dann für jede Bestellung eine Abfrage für den Kunden: 1 + 50 = 51 Abfragen, wo eine oder zwei genügt hätten.
SELECT * FROM orders WHERE created_at > now() - interval '1 day' LIMIT 50;
SELECT * FROM customers WHERE id = 101;
SELECT * FROM customers WHERE id = 102;
... 48 weitere ...Fast immer entsteht das Muster durch objektrelationale Mapper (ORMs) wie Hibernate/JPA, Entity Framework, Django ORM, ActiveRecord oder Sequelize, deren Lazy Loading zugehörige Objekte erst beim ersten Zugriff lädt. Der Code wirkt harmlos, etwa order.customer.name in einem Template, und funktioniert mit zehn Zeilen in der Entwicklungsdatenbank einwandfrei.
Warum es relevant ist
Jede einzelne Abfrage ist günstig, oft ein bis zwei Millisekunden, doch jede bringt einen Netzwerk-Roundtrip, belegt den Connection Pool und erzeugt Arbeit auf dem Datenbankserver. Mit beispielhaften Zahlen fügen 51 Abfragen à 2 ms einem Request, der 10 ms dauern sollte, rund 100 ms hinzu, und die Kosten wachsen linear mit der Seitengröße. Unter Last belegen die zusätzlichen Abfragen Pool-Slots und Datenbank-CPU, sodass auch andere Requests langsamer werden. Damit ist N+1 eine klassische Ursache für Latenz, die mit dem Datenvolumen wächst, und eine versteckte Bremse für den Durchsatz.
Oft schleicht sich das Problem ein: Eine Liste, die früher fünf Einträge zeigte, zeigt nach dem Wachstum eines Kunden 200, und die Antwortzeiten steigen ohne jede Codeänderung.
So erkennen Sie es
In Distributed Traces sind N+1-Abfragen leicht zu erkennen. Unter einem Request-Span erscheint eine lange Treppe aus Datenbank-Spans mit demselben normalisierten Statement und unterschiedlichen Parametern, nacheinander ausgeführt. Hilfreiche Signale:
- Die Zahl der Datenbank-Spans pro Request, vor allem wenn sie mit der Größe des Ergebnisses schwankt.
- Wiederholte gleiche Abfrageformen innerhalb eines Traces, erkennbar an Attributen wie
db.query.textoder einer normalisierten Abfragezusammenfassung aus den OpenTelemetry Semantic Conventions für Datenbanken. - Ein großer Anteil der Request-Dauer entfällt auf viele kurze Datenbankaufrufe statt auf einen langsamen.
- Auf Datenbankseite sehr hohe Aufrufzahlen für einen einfachen Primärschlüssel-Lookup in Statistiken wie
pg_stat_statements.
In der Entwicklung helfen Framework-Werkzeuge, etwa das Bullet-Gem für Rails oder Tests, die fehlschlagen, sobald eine View eine festgelegte Zahl an Abfragen überschreitet.
So beheben Sie es
| Technik | Idee | Beispiele |
|---|---|---|
| Eager Loading per Join | Eltern- und zugehörige Zeilen in einer Abfrage laden | Django select_related, JPA JOIN FETCH, Rails eager_load |
| Batch Loading mit IN | Eine zusätzliche Abfrage für alle zugehörigen Zeilen: WHERE id IN (...) | Django prefetch_related, Rails preload/includes, Hibernate @BatchSize, EF Core Include |
| Batching pro Request | Schlüssel während eines Requests sammeln und gemeinsam auflösen | DataLoader-Muster in GraphQL-Servern |
| Gezielte Abfrage | Nur benötigte Spalten per Join oder View auswählen | Handgeschriebenes SQL, Projektionen, Read Models |
Im Bestellbeispiel reduziert ein einziger Join oder eine zusätzliche IN-Abfrage 51 Roundtrips auf einen oder zwei, und die Kosten wachsen nicht mehr mit der Zahl der Zeilen.
Best Practices
- Die Ladestrategie für Listenansichten und APIs explizit festlegen, statt sich auf ORM-Standards zu verlassen.
- Abfragezahlen kritischer Endpunkte in Integrationstests prüfen.
- Sammlungen paginieren, damit selbst ein unbemerktes N+1 eine Obergrenze hat.
- Datenbank-Spans pro Request im Dashboard beobachten und bei plötzlichen Anstiegen nach Deployments alarmieren.
- Nicht überkorrigieren: Wer alles per Eager Loading lädt, holt oft viel mehr Daten als nötig und erzeugt große, langsame Joins.
Typische Fehler
Häufig wird ein N+1-Problem an einer Stelle behoben, während dieselbe Relation an anderer Stelle weiter per Lazy Loading geladen wird, etwa in einem Serializer oder Template-Helper. Die Zahl der Abfragen ändert sich dann kaum. Ein weiterer Fehler ist, nur mit kleinen Testdaten zu messen, bei denen 1 + 5 Abfragen harmlos wirken. Und manche Teams führen die N Lookups parallel aus, statt sie zu bündeln. Das verkürzt zwar die Wartezeit, belastet Datenbank und Connection Pool aber genauso und kann die Lage unter Last sogar verschlechtern. Die eigentliche Lösung bleibt, die Zahl der Roundtrips zu senken.
Wie Obseria unterstützt
Das Distributed Tracing von Obseria zeigt jeden Datenbankaufruf als Span mit normalisiertem Statement, sodass die Treppe wiederholter Abfragen hinter einem N+1-Muster sofort sichtbar wird. Das Datenbank-Monitoring zeigt dieselbe Abfrage aus Sicht der Datenbank, und AI Code Insights verknüpft eine Regression mit dem Pull Request und den Dateien, die sie eingeführt haben.
