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.
books = Book.objects.()
book books:
(book.author.name)
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.
# ✅ 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.
# ✅ 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.
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.
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.