Jak `select_related` a `prefetch_related` vyřešují problém N+1?

Question

Accepted Answer

Problém **N+1 dotazů** je nejčastější problém s výkonem Django ORM: přístup k asociovaným objektům v cyklu spustí separátní databázový dotaz pro každý z nich. **`select_related`** a **`prefetch_related`** to vyřešují efektivním načítáním asociovaných dat — jsou to nezbytné optimalizační nástroje.

## Problém N+1

```python
# ❌ N+1 queries
books = Book.objects.all()              # 1 query: fetch all books
for book in books:
    print(book.author.name)             # +1 query PER book to fetch its author!
# 100 books → 1 + 100 = 101 queries (terrible performance)
```

Každý přístup `book.author` líně dotazuje databázi znovu. Se 100 knihami to znamená 101 dotazů — vážný a záludný problém s výkonem, který se často objeví až při práci se skutečným objemem dat.

## select_related — pro ForeignKey / OneToOne (SQL JOIN)

```python
# ✅ 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` provede SQL **JOIN** pro načtení asociovaného objektu(ů) ve *stejném* dotazu. Používejte jej pro **přímé ForeignKey a OneToOne** vztahy (jediný asociovaný objekt), kde je JOIN efektivní.

## prefetch_related — pro ManyToMany / zpětný FK (separátní dotaz)

```python
# ✅ 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` spustí **separátní dotaz** na asociované objekty a spojí je v Pythonu. Používejte jej pro **ManyToMany a zpětné ForeignKey** vztahy (více asociovaných objektů), kde by JOIN neefektivně znásobil řádky.

## Kterou použít

```text
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
```

## Detekce problémů N+1

```text
✓ 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.
```

## Proč to má smysl

Problém N+1 dotazů je **jediným nejčastějším a nejvýznamnějším problémem s výkonem** v Django aplikacích a pochopení `select_related`/`prefetch_related` je nezbytné pro psaní výkonného kódu.

Problém je záludný, protože syntaxe ORM, která usnadňuje přístup k asociovaným objektům (`book.author.name`), tiše spouští databázový dotaz pokaždé — kód, který funguje dobře s několika záznamy, katastrofálně degraduje se skutečnými objemy dat (100 záznamů → 101 dotazů), často se objeví až v produkci pod zátěží.

Tyto dva nástroje jsou standardním, nezbytným řešením: **`select_related`** používá SQL JOIN pro načtení přímých ForeignKey/OneToOne vztahů v jediném dotazu, zatímco **`prefetch_related`** používá separátní dotaz (spojený v Pythonu) pro ManyToMany/zpětné-ForeignKey vztahy, kde by byl JOIN neefektivní — a vědět, **kterou použít pro který typ vztahu**, je klíčová dovednost.

Ovládnutí těchto nástrojů změní stovky dotazů na jeden nebo dva, což často dramaticky zlepší výkon stránky.

Tato optimalizace je natolik zásadní, že rozpoznání problémů N+1 (pomocí nástrojů jako Django Debug Toolbar na spotřebu velkého množství dotazů) a aplikace správné opravy je základní kompetencí, která rozlišuje vývojáře, kteří píšou efektivní Django kód, od těch, jejichž aplikace se zpomalují na plazivou chůzi, jak data rostou.

Je to také mezi nejčastěji testovanými Django interview tématy, přesně proto, že to odráží praktické, výkonem kritické pochopení ORM.