N+1-forespørgselproblemet er det mest almindelige Django ORM-ydeelsesproblem: at få adgang til relaterede objekter i en løkke udløser en separat databaseforespørgsel for hver enkelt. select_related og prefetch_related løser det ved effektivt at hente relaterede data — de er væsentlige optimeringsværktøjer.
books = Book.objects.()
book books:
(book.author.name)
Hver book.author-adgang forespørger databasen på ny. Med 100 bøger er det 101 forespørgelser — en alvorlig, skjult ydeelsestapper, der ofte først viser sig med rigtige datamængder.
# ✅ 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 udfører en SQL JOIN for at hente det relaterede objekt (objekterne) i den samme forespørgsel. Brug det til forward ForeignKey og OneToOne relationer (enkelt relateret objekt), hvor 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 kører en separat forespørgsel for de relaterede objekter og kombinerer dem i Python. Brug det til ManyToMany og reverse ForeignKey relationer (flere relaterede objekter), hvor en JOIN ville multiplicere rækker 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-forespørgselproblemet er det eneste mest almindelige og indvirkende ydeelsesproblem i Django-applikationer, og det er vigtigt at forstå select_related/prefetch_related for at skrive performant kode.
Problemet er lumsk, fordi den praktiske ORM-syntaks, der gør det så nemt at få adgang til relaterede objekter (book.author.name), stilfærdig udløser en databaseforespørgsel hver gang — kode, der fungerer fint med nogle få poster, forringes katastrofalt med rigtige datamængder (100 poster → 101 forespørgelser), og det opdages ofte først i production under belastning.
Disse to værktøjer er standardløsningen og er vigtige: select_related bruger en SQL JOIN til at hente forward ForeignKey/OneToOne-relationer i en enkelt forespørgsel, mens prefetch_related bruger en separat forespørgsel (kombineret i Python) til ManyToMany/reverse-ForeignKey-relationer, hvor en JOIN ville være ineffektiv — og at vide hvilken man skal bruge til hvilken relationtype er nøglefærdigheden.
Mestring af dem omdanner hundredvis af forespørgelser til en eller to, hvilket ofte forbedrer sidens ydeevne dramatisk.
Denne optimering er så grundlæggende, at genkendelse af N+1-problemer (ved hjælp af værktøjer som Django Debug Toolbar til at påvise overdrevne forespørgselsantal) og anvendelse af den rette rettelse er en kernen kompetence, der skelner udvikler, der skriver effektiv Django-kode, fra dem, hvis apps bliver langsommere, når dataene vokser.
Det er også blandt de mest hyppigt testede Django-interviewemner, præcis fordi det afspejler praktisk, ydelseskrisk ORM-forståelse.