N+1-spørsmålet er det vanligste Django ORM-ytelsesproblemet: å få tilgang til relaterte objekter i en løkke utløser en separat databasespørring for hver enkelt. select_related og prefetch_related løser det ved å hente relaterte data effektivt — de er essensielle optimeringsverktøy.
books = Book.objects.()
book books:
(book.author.name)
Hver book.author-tilgang gjør lat spørring til databasen igjen. Med 100 bøker er det 101 spørringer — en alvorlig, skjult ytelsesdreperen som ofte først dukker opp under reell datamengde.
# ✅ 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 utfører en SQL JOIN for å hente det/de relaterte objektet(ene) i samme spørring. Bruk det for forward ForeignKey og OneToOne-relasjoner (enkelt relatert objekt), der en JOIN er effektiv.
# ✅ 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 kjører en separat spørring for de relaterte objektene og slår dem sammen i Python. Bruk det for ManyToMany og reverse ForeignKey-relasjoner (flere relaterte objekter), der en JOIN ville multiplisere rader ineffektivt.
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-spørsmålet er det enkelte vanligste og mest påvirkende ytelsesproblemet i Django-applikasjoner, og å forstå select_related/prefetch_related er essensielt for å skrive effektiv kode.
Problemet er giftig fordi den praktiske ORM-syntaksen som gjør det så enkelt å få tilgang til relaterte objekter (book.author.name) stilltiende utløser en databasespørring hver gang — kode som fungerer fint med noen få poster degraderes katastrofalt med reell datamengde (100 poster → 101 spørringer), ofte først oppdaget i produksjon under belastning.
Disse to verktøyene er standard, essensielle løsningen: select_related bruker en SQL JOIN for å hente forward ForeignKey/OneToOne-relasjoner i en enkelt spørring, mens prefetch_related bruker en separat spørring (slått sammen i Python) for ManyToMany/reverse-ForeignKey-relasjoner der en JOIN ville være ineffektiv — og å vite hvilken som skal brukes for hvilken relasjontype er nøkkelferdigheten.
Å mestre dem gjør hundrevis av spørringer til en eller to, og forbedrer ofte sidens ytelse dramatisk.
Denne optimaliseringen er så fundamental at å gjenkjenne N+1-problemer (ved å bruke verktøy som Django Debug Toolbar for å oppdage overdrevne spørringstellinger) og bruke riktig løsning er en kjernekompetanse som skiller utviklere som skriver effektiv Django-kode fra de hvis apper bremser ned når data vokser.
Det er også blant de hyppigst testede Django-intervjutemaene, nettopp fordi det reflekterer praktisk, ytelses-kritisk ORM-forståelse.