N+1 užklausų problema yra dažniausia Django ORM našumo problema: pasiekus susijusius objektus kilpoje, kiekvienam iš jų atliekama atskira duomenų bazės užklausa. select_related ir prefetch_related ją sprendžia efektyviai nusikraupdami susijusiais duomenimis — jie yra esminiai optimizavimo įrankiai.
books = Book.objects.()
book books:
(book.author.name)
Kiekvienas book.author prieigos aktas atidžiai vėl užklausia duomenų bazę. Su 100 knygų, tai yra 101 užklausa — rimtas, slaptas našumo žudikas, kuris dažnai pasirodo tik su realiais duomenų kiekiais.
# ✅ 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 atlieka SQL JOIN, kad nusikrautų susijusius objektus toje pačioje užklausoje. Naudokite jį tiesioginiams ForeignKey ir OneToOne ryšiams (vienas susijęs objektas), kur JOIN yra efektyvus.
# ✅ 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 vykdo atskirą užklausą dėl susijusių objektų ir sujungia juos Python. Naudokite jį ManyToMany ir atgaliniam ForeignKey ryšiams (keli susiję objektai), kur JOIN neefektyviai padaugintų eilutes.
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.
N+1 užklausų problema yra vienintelė dažniausia ir svarbiausią įtaką daranti Django aplikacijų našumo problema, ir suprasti select_related/prefetch_related yra būtina, norint rašyti efektyvų kodą.
Problema yra nepastebimy, nes patogi ORM sintaksė, dėl kurios prieiga prie susijusių objektų yra tokia paprasta (book.author.name), tyliai suaktyvina duomenų bazės užklausą kiekvieną kartą — kodas, kuris veikia gerai su keliais įrašais, katastrofiškai pablogėja su realiais duomenų kiekiais (100 įrašų → 101 užklausa), dažnai negrąžinant tik esant realiai apkrovai.
Šie du įrankiai yra standartinis, esmingas sprendimas: select_related naudoja SQL JOIN, norint nusikrauti tiesioginiams ForeignKey/OneToOne ryšiams vieno užklauso metu, o prefetch_related naudoja atskirą užklausą (sujungtą Python), skirtą ManyToMany/atgaliniam-ForeignKey ryšiams, kur JOIN būtų neefektyvus — ir žinoti kurį naudoti kokiems ryšiams yra pagrindinis įgūdis.
Jų įvaldant šimtai užklausų paverčiami viena ar dviem, dažnai dramatiškai pagerinant puslapio našumą.
Ši optimizacija yra tokia pagrindinė, kad N+1 problemų atpažinimas (naudojant tokius įrankius kaip Django Debug Toolbar, norint aptikti per daug užklausų) ir tinkamo pataisymo taikymas yra esminė kompetencija, kuri skiria kūrėjus, rašančius efektyvų Django kodą, nuo tų, kurių aplikacijos sulėtėja augant duomenims.
Tai taip pat vienas iš dažniausiai testuojamų Django interviu klausimų, kaip tik todėl, kad jis atspindi praktinį, našumui kritinį ORM supratimą.