Az N+1 lekérdezés probléma a Django ORM leggyakoribb teljesítményi problémája: a kapcsolódó objektumokhoz való hozzáférés egy cikluson belül egy külön adatbázis-lekérdezést indít el mindegyikhez. A select_related és a prefetch_related ezt úgy oldja meg, hogy hatékonyan beolvassa a kapcsolódó adatokat — ezek alapvető optimalizálási eszközök.
books = Book.objects.()
book books:
(book.author.name)
Minden book.author hozzáférés újabb, lusta lekérdezést végez az adatbázisban. 100 könyvnél ez 101 lekérdezés — egy súlyos, rejtett teljesítményi problémakeltő, amely gyakran csak nagy adatmennyiség alatt jelentkezik.
# ✅ 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
A select_related egy SQL JOIN műveletet végez a kapcsolódó objektum(ok) beolvasásához ugyanabban a lekérdezésben. Használd előre mutató ForeignKey és OneToOne kapcsolatoknál (egyetlen kapcsolódó objektum), ahol a JOIN hatékony.
# ✅ 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
A prefetch_related egy külön lekérdezést futtat a kapcsolódó objektumokhoz és Python-ban egyesíti őket. Használd ManyToMany és fordított ForeignKey kapcsolatoknál (több kapcsolódó objektum), ahol a JOIN nem lenne hatékony, mert szorzatot adna a soroknak.
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.
Az N+1 lekérdezés probléma a Django alkalmazások egyetlen leggyakoribb és leghatásosabb teljesítményi problémája, és a select_related/prefetch_related megértése alapvető fontosságú a hatékony kód írásához.
A probléma tétova, mivel az a kényelmes ORM szintaxis, amely olyan egyszerűvé teszi a kapcsolódó objektumokhoz való hozzáférést (book.author.name), csendesen indít el egy adatbázis-lekérdezést minden alkalommal — olyan kód, amely kevés rekorddal tökéletesen működik, katasztrofálisan leromlott az igazi adatmennyiséggel (100 rekord → 101 lekérdezés), és gyakran csak termelésben, nagy terhelés alatt fedezik fel.
Ez a két eszköz a standard, alapvető megoldás: a select_related egy SQL JOIN-t használ az előre mutató ForeignKey/OneToOne kapcsolatok egyetlen lekérdezésben való beolvasásához, míg a prefetch_related egy külön lekérdezést használ (Python-ban egyesítve) a ManyToMany/fordított ForeignKey kapcsolatoknál, ahol a JOIN nem lenne hatékony — és az ismeret, hogy melyiket melyik kapcsolattípushoz használjad, az alapvető készség.
Mesterien alkalmazva ezek több száz lekérdezést egy vagy kettőre redukálnak, gyakran drámaiasan javítva az oldal teljesítményét.
Ez az optimalizálás olyan alapvető, hogy az N+1 problémák felismerése (olyan eszközök használatával, mint a Django Debug Toolbar a feloldott lekérdezésszám észlelésére) és a megfelelő javítás alkalmazása olyan alapkompetencia, amely megkülönböztet azon fejlesztőket, akik hatékony Django kódot írnak azoktól, akiknek az alkalmazásai az adatok növekedésével lelassulnak.
Ez is a leggyakrabban tesztelt Django interjúkérdések közé tartozik, pontosan azért, mert a gyakorlati, teljesítménykritikus ORM-megértést tükröz.