Il problema della query N+1 è il problema di performance più comune dell'ORM di Django: accedere agli oggetti correlati in un ciclo innesca una query di database separata per ognuno. select_related e prefetch_related lo risolvono recuperando i dati correlati in modo efficiente — sono strumenti di ottimizzazione essenziali.
books = Book.objects.()
book books:
(book.author.name)
Ogni accesso a book.author interroga il database con lazy loading ancora una volta. Con 100 libri, sono 101 query — un killer di performance grave e subdolo che spesso emerge solo con volumi di dati reali.
# ✅ 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 esegue un JOIN SQL per recuperare gli oggetti correlati nella stessa query. Usalo per relazioni ForeignKey forward e OneToOne (oggetto correlato singolo), dove un JOIN è efficiente.
# ✅ 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 esegue una query separata per gli oggetti correlati e li unisce in Python. Usalo per relazioni ManyToMany e ForeignKey inversa (oggetti correlati multipli), dove un JOIN moltiplicherebbe le righe in modo inefficiente.
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.
Il problema della query N+1 è il singolo problema di performance più comune e impattante nelle applicazioni Django, e comprendere select_related/prefetch_related è essenziale per scrivere codice performante.
Il problema è insidioso perché la sintassi ORM conveniente che rende l'accesso agli oggetti correlati così facile (book.author.name) innesca silenziosamente una query di database ogni volta — il codice che funziona bene con pochi record si degrada catastroficamente con volumi di dati reali (100 record → 101 query), spesso scoperto solo in produzione sotto carico.
Questi due strumenti sono la soluzione standard e essenziale: select_related usa un JOIN SQL per recuperare relazioni ForeignKey forward/OneToOne in una singola query, mentre prefetch_related usa una query separata (unita in Python) per relazioni ManyToMany/ForeignKey inversa dove un JOIN sarebbe inefficiente — e sapere quale usare per quale tipo di relazione è la competenza chiave.
Padroneggiare questi strumenti trasforma centinaia di query in una o due, spesso migliorando drammaticamente le performance della pagina.
Questa ottimizzazione è così fondamentale che riconoscere i problemi N+1 (usando strumenti come Django Debug Toolbar per individuare conteggi di query eccessivi) e applicare la correzione giusta è una competenza fondamentale che distingue gli sviluppatori che scrivono codice Django efficiente da quelli le cui app rallentano fino a bloccarsi mentre i dati crescono.
È anche tra gli argomenti di intervista Django più frequentemente testati, precisamente perché riflette la comprensione pratica e critica per le performance dell'ORM.