Como `select_related` e `prefetch_related` evitam o problema N+1?

Question

IT Interview Practice · Accepted Answer

O **problema de consultas N+1** é a questão de performance mais comum do Django ORM: acessar objetos relacionados em um loop dispara uma consulta ao banco de dados separada para cada um. **`select_related`** e **`prefetch_related`** resolvem isso buscando dados relacionados de forma eficiente — são ferramentas de otimização essenciais.

## O problema 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)
```

Cada acesso a `book.author` consulta o banco de dados novamente com lazy loading. Com 100 livros, isso resulta em 101 consultas — um assassino de performance severo e sorrateiro que frequentemente só aparece com volumes reais de dados.

## select_related — para 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` executa um **JOIN** SQL para buscar o(s) objeto(s) relacionado(s) na *mesma* consulta. Use-o para relacionamentos **ForeignKey direto e OneToOne** (objeto relacionado único), onde um JOIN é eficiente.

## prefetch_related — para ManyToMany / FK reverso (consulta separada)

```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` executa uma **consulta separada** para os objetos relacionados e os une em Python. Use-o para relacionamentos **ManyToMany e ForeignKey reverso** (múltiplos objetos relacionados), onde um JOIN multiplicaria linhas de forma ineficiente.

## Qual usar

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

## Detectando problemas 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.
```

## Por que isso importa

O problema de consultas N+1 é a **questão de performance mais comum e impactante** em aplicações Django, e entender `select_related`/`prefetch_related` é essencial para escrever código performático.

O problema é insidioso porque a sintaxe conveniente do ORM que torna acessar objetos relacionados tão fácil (`book.author.name`) dispara silenciosamente uma consulta ao banco de dados a cada vez — código que funciona bem com alguns registros se degrada catastroficamente com volumes reais de dados (100 registros → 101 consultas), frequentemente descoberto apenas em produção sob carga.

Essas duas ferramentas são a solução padrão e essencial: **`select_related`** usa um JOIN SQL para buscar relacionamentos ForeignKey/OneToOne diretos em uma única consulta, enquanto **`prefetch_related`** usa uma consulta separada (unida em Python) para relacionamentos ManyToMany/ForeignKey-reverso onde um JOIN seria ineficiente — e saber **qual usar para qual tipo de relacionamento** é a habilidade-chave.

Dominar essas ferramentas transforma centenas de consultas em uma ou duas, frequentemente melhorando a performance de página dramaticamente.

Essa otimização é tão fundamental que reconhecer problemas N+1 (usando ferramentas como Django Debug Toolbar para identificar contagens excessivas de consultas) e aplicar a correção certa é uma competência central que distingue desenvolvedores que escrevem código Django eficiente daqueles cujas aplicações ficam lentas conforme os dados crescem.

Além disso, é um dos tópicos de entrevista Django mais frequentemente testados, precisamente porque reflete entendimento prático e crítico de performance do ORM.

O problema N+1

select_related — para ForeignKey / OneToOne (SQL JOIN)

prefetch_related — para ManyToMany / FK reverso (consulta separada)

Qual usar

Detectando problemas N+1

Por que isso importa

Perguntas relacionadas