Comment traqueriez-vous et corrigeriez-vous un problème de requêtes N+1 dans une application Django ?

Confirmez-le d'abord en comptant les requêtes, avec Django Debug Toolbar en local ou assertNumQueries dans un test. Le motif est une boucle qui touche un objet lié, ce qui déclenche une requête par ligne parce que les querysets sont paresseux. Corrigez les relations directes avec select_related, qui fait une jointure, et les relations inverses ou plusieurs-à-plusieurs avec prefetch_related, qui lance une requête supplémentaire.

La mesure vient en premier, parce que deviner les performances d'un ORM, c'est perdre un après-midi. En local j'active la debug toolbar ou je journalise les requêtes en niveau debug, et si c'est déjà en production je regarde la trace, où un endpoint qui tire quatre cents selects presque identiques ne trompe personne. La cause est qu'un queryset ne touche la base que quand vous l'itérez, et accéder à une clé étrangère sur chaque ligne va chercher paresseusement cette relation. Pour une clé étrangère directe j'ajoute select_related, qui transforme cela en une jointure et une seule requête. Pour les relations inverses ou plusieurs-à-plusieurs j'utilise prefetch_related, qui émet une seconde requête et recoud les résultats côté Python. Une fois corrigé, j'écris un test qui enveloppe la vue dans assertNumQueries avec le nombre attendu, sinon la personne suivante ajoute un champ dans le template et la régression passe inaperçue. Sur un tableau de bord interne nous sommes passés d'environ trois cents requêtes à quatre sur une page, et le temps de chargement d'environ deux secondes à moins de deux cents millisecondes.