Was ist das N-plus-eins-Query-Problem und wie behebst du es?

Du führst eine Query aus, um eine Liste zu holen, läufst dann über die Zeilen und setzt pro Zeile eine weitere Query ab, aus 200 Posts werden also 201 Roundtrips. Behebe es, indem du die verwandten Zeilen in einem Durchgang lädst: ein Join, eine IN-Query nach Parent-Id oder ein Batching-Loader, der Ids innerhalb eines Request-Ticks sammelt. Das Erkennungsmerkmal ist Latenz, die linear mit der Ergebnisanzahl wächst, während jede einzelne Query schnell aussieht.

Es taucht meistens genau dann auf, wenn jemand eine Liste rendert. Du holst Bestellungen, im Template greifst du dann auf order.customer.name zu, und das ORM setzt still eine Query pro Zeile ab. Einzeln sind das eine halbe Millisekunde, es sieht also nichts kaputt aus, bis die Liste wächst und der Endpoint vier Sekunden braucht. Ich entdecke es, indem ich auf die Query-Anzahl pro Request schaue statt auf die Query-Dauer; die meisten APM-Tools zeigen das direkt, und lokal schalte ich Query-Logging an und zähle. Der Fix hängt von der Form ab. Bei einer einfachen Belongs-to-Beziehung ist Eager Loading oder ein Join in Ordnung. Bei einer Eins-zu-viele-Beziehung, bei der ein Join Zeilen vervielfachen würde, nehme ich lieber eine zweite Query mit einer IN-Klausel und setze im Speicher zusammen. In einer GraphQL-API muss es ein Dataloader sein, weil Resolver keine Ahnung haben, dass sie im Batch aufgerufen werden. Was ich vermeide, ist alles standardmäßig eager zu laden, weil du damit ein Problem gegen das Ziehen der halben Datenbank in den Speicher tauschst.