N+1-frågeproblem är det vanligaste prestandaproblemen i Django ORM: att komma åt relaterade objekt i en loop utlöser en separat databasfråga för var och en. select_related och prefetch_related löser det genom att hämta relaterad data effektivt — de är viktiga optimeringsverktyg.
books = Book.objects.()
book books:
(book.author.name)
Varje book.author-åtkomst gör en lat databasfråga igen. Med 100 böcker blir det 101 frågor — ett allvarligt, dolt prestandaproblem som ofta bara visar sig med verklig datamängd.
# ✅ 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ör ett SQL JOIN för att hämta det relaterade objektet (eller objekten) i samma fråga. Använd det för forward ForeignKey och OneToOne relationer (enstaka relaterat objekt), där ett JOIN är effektivt.
# ✅ 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 kör en separat fråga för de relaterade objekten och slår ihop dem i Python. Använd det för ManyToMany och reverse ForeignKey relationer (flera relaterade objekt), där ett JOIN skulle multiplicera raderna 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-frågeproblem är det enskilt vanligaste och mest påverkande prestandaproblemen i Django-applikationer, och att förstå select_related/prefetch_related är väsentligt för att skriva performant kod.
Problemet är försåtligt eftersom den bekväma ORM-syntaxen som gör det så enkelt att komma åt relaterade objekt (book.author.name) tyst utlöser en databasfråga varje gång — kod som fungerar bra med få poster blir katastrofal med verklig datamängd (100 poster → 101 frågor), ofta bara upptäckt i produktion under belastning.
Dessa två verktyg är standardlösningen och är väsentlig: select_related använder ett SQL JOIN för att hämta forward ForeignKey/OneToOne-relationer i en enda fråga, medan prefetch_related använder en separat fråga (sammanfogad i Python) för ManyToMany/reverse-ForeignKey-relationer där ett JOIN skulle vara ineffektivt — och att veta vilket som ska användas för vilken relationstyp är den avgörande färdigheten.
Att behärska dem omvandlar hundratals frågor till en eller två, ofta med dramatisk förbättring av sidans prestanda.
Denna optimering är så fundamental att kunna känna igen N+1-problem (med hjälp av verktyg som Django Debug Toolbar för att se överflödiga frågetal) och tillämpa rätt lösning är en kärnkompetens som skiljer utvecklare som skriver effektiv Django-kod från dem vars appar saktar ner när data växer.
Det är också bland de oftast testade Django-intervjuämnen, just därför att det återspeglar praktisk, prestandakritisk ORM-förståelse.