Qu'est-ce que le problème des N plus une requêtes et comment le corrigez-vous ?

Vous lancez une requête pour récupérer une liste, puis vous bouclez sur les lignes et vous émettez une autre requête par ligne, donc 200 posts deviennent 201 allers-retours. Corrigez-le en chargeant les lignes liées en une seule passe : une jointure, une requête IN indexée par identifiant parent, ou un loader qui regroupe les identifiants dans le même tick de requête. Le symptôme, c'est une latence qui croît linéairement avec le nombre de résultats alors que chaque requête individuelle paraît rapide.

Ça apparaît en général dès que quelqu'un affiche une liste. Vous récupérez des commandes, puis dans le template vous touchez order.customer.name, et l'ORM émet discrètement une requête par ligne. Individuellement elles font une demi-milliseconde, donc rien ne semble cassé jusqu'à ce que la liste grossisse et que l'endpoint mette quatre secondes. Je le détecte en regardant le nombre de requêtes par requête HTTP plutôt que leur durée ; la plupart des outils d'APM le montrent directement, et en local j'active la journalisation des requêtes et je compte. Le correctif dépend de la forme. Pour une relation belongs to simple, un chargement anticipé ou une jointure suffit. Pour un un-à-plusieurs où une jointure multiplierait les lignes, je préfère une deuxième requête avec une clause IN et un assemblage en mémoire. Dans une API GraphQL, il faut un dataloader, parce que les resolvers n'ont aucune idée qu'ils sont appelés en lot. Ce que j'évite, c'est le chargement anticipé de tout par défaut, puisque ça échange un problème contre le fait de tirer la moitié de la base en mémoire.