Problem N+1 poizvedb je najpogostejši problem z zmogljivostjo Django ORM-a: dostop do povezanih objektov v zanki sproži ločeno podatkovno poizvedbo za vsakega. select_related in prefetch_related ga rešita z učinkovitim pridobivanjem povezanih podatkov — to so nujni optimizacijski pripomočki.
books = Book.objects.()
book books:
(book.author.name)
Vsak dostop book.author lenobo poizvedi bazo podatkov znova. Pri 100 knjigah je to 101 poizvedb — resna in prikrita past zmogljivosti, ki se pogosto pojavi šele pri realnih količinah podatkov.
# ✅ 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 izvede SQL JOIN, da pridobi povezane objekte v isti poizvedbi. Uporabljajte ga za napredne ForeignKey in OneToOne relacije (en sam povezan objekt), kjer je JOIN učinkovit.
# ✅ 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 izvede ločeno poizvedbo za povezane objekte in jih poveže v Pythonu. Uporabljajte ga za ManyToMany in obratne ForeignKey relacije (več povezanih objektov), kjer bi JOIN nepotrebno pomnožil vrstice.
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.
Problem N+1 poizvedb je edini najpogostejši in najbolj vplivni problem zmogljivosti v Django aplikacijah, razumevanje select_related/prefetch_related pa je nujno za pisanje učinkovitega koda.
Probljem je prikrit, ker zgledna ORM sintaksa, ki dostop do povezanih objektov tako preprost (book.author.name) lenobo sproži podatkovno poizvedbo vsakič — koda, ki deluje dobro z nekaj zapisi, pa katastrofalno pade pri realnih podatkih (100 zapisov → 101 poizvedb), pogosto se odkrije šele v produkciji pod obremenitvijo.
Ta dva orodja sta standardna, nujno potrebna rešitev: select_related uporablja SQL JOIN za pridobivanje naprednih ForeignKey/OneToOne relacij v eni poizvedbi, medtem ko prefetch_related uporablja ločeno poizvedbo (povezano v Pythonu) za ManyToMany/obratne ForeignKey relacije, kjer bi bil JOIN neučinkovit — in poznavanje katero uporabiti za katero vrsto relacije je ključna spretnost.
Ovladavanje teh dveh orodij stotine poizvedb spremeni v eno ali dve, kar pogosto dramatično izboljša zmogljivost strani.
Ta optimizacija je tako temeljna, da je prepoznavanje N+1 problemov (z orodji, kot je Django Debug Toolbar, za opazovanje prevelikih števil poizvedb) in uporaba prave rešitve temeljnega pomena, ki loči razvojnike, ki pišejo učinkovit Django kod, od tistih, katerih aplikacije počasnijo, ko rastejo podatki.
Med najbolj pogosto testiranimi temami Django intervjujev je tudi zato, ker odraža praktično, zmogljivostno kritično razumevanje ORM-a.