Problema N+1 query este cea mai frecventă problemă de performanță a Django ORM: accesarea obiectelor asociate într-o buclă declanșează o interogare separată a bazei de date pentru fiecare. select_related și prefetch_related o rezolvă prin preluarea eficientă a datelor asociate — sunt instrumente de optimizare esențiale.
books = Book.objects.()
book books:
(book.author.name)
Fiecare acces book.author interoghează lazy baza de date din nou. Cu 100 de cărți, asta înseamnă 101 interogări — o problemă de performanță severă și ascunsă care apare adesea doar sub volume reale de date.
# ✅ 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 realizează un SQL JOIN pentru a prelua obiectul(ele) asociat(e) în aceeași interogare. Folosiți-l pentru relații ForeignKey și OneToOne directe (obiect asociat unic), unde un JOIN este eficient.
# ✅ 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 rulează o interogare separată pentru obiectele asociate și le unește în Python. Folosiți-l pentru relații ManyToMany și ForeignKey inverse (obiecte asociate multiple), unde un JOIN ar multiplica rândurile ineficient.
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.
Problema N+1 query este cea mai frecventă și impactantă problemă de performanță în aplicațiile Django, iar înțelegerea select_related/prefetch_related este esențială pentru scrierea unui cod performant.
Problema este insidioasă deoarece sintaxa convenabilă a ORM care face accesarea obiectelor asociate atât de ușoară (book.author.name) declanșează tăcut o interogare a bazei de date de fiecare dată — codul care funcționează bine cu câteva înregistrări se degradează catastrofal cu volume reale de date (100 înregistrări → 101 interogări), adesea descoperit doar în producție sub sarcină.
Aceste două instrumente sunt soluția standard și esențială: select_related folosește un SQL JOIN pentru a prelua relații ForeignKey/OneToOne directe într-o singură interogare, în timp ce prefetch_related folosește o interogare separată (unită în Python) pentru relații ManyToMany/ForeignKey inverse unde un JOIN ar fi ineficient — iar cunoașterea care să se folosească pentru fiecare tip de relație este abilitatea cheie.
Stăpânirea lor transformă sute de interogări în una sau două, îmbunătățind adesea performanța paginii dramatic.
Această optimizare este atât de fundamentală încât recunoașterea problemelor N+1 (folosind instrumente cum ar fi Django Debug Toolbar pentru a detecta numere excessive de interogări) și aplicarea corecției potrivite este o competență de bază care diferențiază dezvoltatorii care scriu cod Django eficient de cei ale căror aplicații încetinesc pe măsură ce datele cresc.
Este, de asemenea, printre cele mai frecvent testate subiecte Django din interviuri, tocmai pentru că reflectă înțelegerea ORM practică și critică din punct de vedere al performanței.