Le problème de requête N+1 est le problème de performance le plus courant avec l'ORM Django : accéder à des objets liés dans une boucle déclenche une requête de base de données distincte pour chacun. select_related et prefetch_related le résolvent en récupérant les données liées efficacement — ce sont des outils d'optimisation essentiels.
books = Book.objects.()
book books:
(book.author.name)
Chaque accès à book.author interroge la base de données de manière lazy. Avec 100 livres, cela fait 101 requêtes — un tueur de performance sérieux et insidieux qui ne fait surface que sous de vrais volumes de données.
# ✅ ONE query with a JOIN
books = Book.objects.select_related("author").all()
for book in books:
print(book.author.name) # NO extra queries — author was JOINed in
# 100 books → 1 query total
select_related effectue une JOIN SQL pour récupérer le(s) objet(s) lié(s) dans la même requête. Utilisez-le pour les relations ForeignKey directe et OneToOne (objet lié unique), où une JOIN est efficace.
# ✅ TWO queries total (not N+1)
authors = Author.objects.prefetch_related("books").all()
for author in authors:
for book in author.books.all(): # NO extra queries — books were prefetched
print(book.title)
# query 1: all authors; query 2: all their books → Django joins them in Python
prefetch_related exécute une requête distincte pour les objets liés et les joint en Python. Utilisez-le pour les relations ManyToMany et ForeignKey inverse (objets liés multiples), où une JOIN multiplierait les lignes inefficacement.
select_related → ForeignKey, OneToOne (forward, single object) → SQL JOIN, 1 query
prefetch_related → ManyToMany, reverse ForeignKey (many objects) → 2 queries, joined in Python
You can combine and chain them, and span relationships:
Book.objects.select_related("author").prefetch_related("tags")
Book.objects.select_related("author__publisher") # multi-level
✓ Django Debug Toolbar — shows the query count per page (spot N+1 visually)
✓ django-silk, or logging queries (connection.queries) to count them
→ If a page runs hundreds of similar queries, you likely have an N+1.
Le problème de requête N+1 est le problème de performance unique le plus courant et impactant dans les applications Django, et comprendre select_related/prefetch_related est essentiel pour écrire du code performant.
Le problème est insidieux parce que la syntaxe pratique de l'ORM qui rend l'accès aux objets liés si facile (book.author.name) déclenche silencieusement une requête de base de données à chaque fois — le code qui fonctionne bien avec quelques enregistrements se dégrade catastrophiquement avec de vrais volumes de données (100 enregistrements → 101 requêtes), souvent découvert seulement en production sous charge.
Ces deux outils sont la solution standard et essentielle : select_related utilise une JOIN SQL pour récupérer les relations ForeignKey/OneToOne directes en une seule requête, tandis que prefetch_related utilise une requête distincte (jointe en Python) pour les relations ManyToMany/ForeignKey inverse où une JOIN serait inefficace — et savoir lequel utiliser pour quel type de relation est la compétence clé.
Les maîtriser transforme des centaines de requêtes en une ou deux, améliorant souvent dramatiquement la performance des pages.
Cette optimisation est tellement fondamentale que reconnaître les problèmes N+1 (en utilisant des outils comme Django Debug Toolbar pour repérer les excès de requêtes) et appliquer la bonne correction est une compétence fondamentale qui distingue les développeurs qui écrivent du code Django efficace de ceux dont les applications ralentissent à mesure que les données augmentent.
C'est aussi l'un des sujets d'entretien Django les plus fréquemment testés, précisément parce qu'il reflète une compréhension de l'ORM pratique et critique en termes de performance.