Problem N+1 queries to najczęstszy problem wydajności Django ORM: dostęp do powiązanych obiektów w pętli wyzwala oddzielne zapytanie do bazy danych dla każdego z nich. select_related i prefetch_related rozwiązują ten problem poprzez wydajne pobranie powiązanych danych — są to niezbędne narzędzia optymalizacyjne.
books = Book.objects.()
book books:
(book.author.name)
Każdy dostęp do book.author leniwie wykonuje zapytanie do bazy danych ponownie. Ze 100 książkami to 101 zapytań — poważny i podstępny zabójca wydajności, który często pojawia się dopiero przy rzeczywistych wolumenach danych.
# ✅ 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 wykonuje SQL JOIN, aby pobrać powiązany obiekt (obiekty) w tym samym zapytaniu. Używaj go dla relacji forward ForeignKey i OneToOne (pojedynczy powiązany obiekt), gdzie JOIN jest wydajny.
# ✅ 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 wykonuje oddzielne zapytanie dla powiązanych obiektów i łączy je w Pythonie. Używaj go dla relacji ManyToMany i reverse ForeignKey (wiele powiązanych obiektów), gdzie JOIN mnożyłby wiersze nieefektywnie.
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.
Problem N+1 queries to jednorazowo najczęstszy i największy problem wydajności w aplikacjach Django, a zrozumienie select_related/prefetch_related jest niezbędne do pisania wydajnego kodu.
Problem jest podstępny, ponieważ wygodna składnia ORM, która sprawia, że dostęp do powiązanych obiektów jest tak łatwy (book.author.name), po cichu wyzwala zapytanie do bazy danych każdorazowo — kod, który działa poprawnie z kilkoma rekordami, degraduje się katastrofalnie przy rzeczywistych wolumenach danych (100 rekordów → 101 zapytań), często odkrywane dopiero w produkcji pod obciążeniem.
Te dwa narzędzia są standardowym, niezbędnym rozwiązaniem: select_related używa SQL JOIN do pobrania relacji forward ForeignKey/OneToOne w jednym zapytaniu, podczas gdy prefetch_related używa oddzielnego zapytania (połączonego w Pythonie) dla relacji ManyToMany/reverse-ForeignKey, gdzie JOIN byłby nieefektywny — a wiedza które narzędzie wybrać dla którego typu relacji to kluczowa umiejętność.
Opanowanie ich zmienia setki zapytań na jedno lub dwa, często dramatycznie poprawiając wydajność strony.
Ta optymalizacja jest na tyle fundamentalna, że rozpoznawanie problemów N+1 (używając narzędzi takich jak Django Debug Toolbar do wykrycia nadmiernej liczby zapytań) i stosowanie właściwej poprawki to kompetencja podstawowa, która odróżnia programistów piszących wydajny kod Django od tych, których aplikacje spowalniają się wraz ze wzrostem danych.
To również jeden z najczęściej testowanych tematów Django w rozmowach kwalifikacyjnych, właśnie dlatego, że odzwierciedla praktyczne, krytyczne dla wydajności zrozumienie ORM.