El problema de consulta N+1 es el problema de rendimiento más común del ORM de Django: acceder a objetos relacionados en un bucle desencadena una consulta de base de datos separada para cada uno. select_related y prefetch_related lo resuelven obteniendo datos relacionados de manera eficiente — son herramientas de optimización esenciales.
books = Book.objects.()
book books:
(book.author.name)
Cada acceso a book.author consulta la base de datos nuevamente de forma perezosa. Con 100 libros, eso son 101 consultas — un eliminador de rendimiento grave y sigiloso que a menudo solo surge bajo volúmenes de datos reales.
# ✅ 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 realiza un JOIN SQL para obtener los objetos relacionados en la misma consulta. Úsalo para relaciones ForeignKey directas y OneToOne (objeto relacionado único), donde un JOIN es 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 ejecuta una consulta separada para los objetos relacionados y los une en Python. Úsalo para relaciones ManyToMany y ForeignKey inversa (múltiples objetos relacionados), donde un JOIN multiplicaría las filas de manera 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.
El problema de consulta N+1 es el problema de rendimiento único más común e impactante en aplicaciones Django, y comprender select_related/prefetch_related es esencial para escribir código eficiente.
El problema es insidioso porque la sintaxis conveniente del ORM que facilita el acceso a objetos relacionados (book.author.name) dispara silenciosamente una consulta de base de datos cada vez — código que funciona bien con pocos registros se degrada catastróficamente con volúmenes de datos reales (100 registros → 101 consultas), a menudo solo descubierto en producción bajo carga.
Estas dos herramientas son la solución estándar esencial: select_related usa un JOIN SQL para obtener relaciones ForeignKey/OneToOne directas en una única consulta, mientras que prefetch_related usa una consulta separada (unida en Python) para relaciones ManyToMany/ForeignKey inversa donde un JOIN sería ineficiente — y saber cuál usar para qué tipo de relación es la habilidad clave.
Dominarlas convierte cientos de consultas en una o dos, a menudo mejorando el rendimiento de la página dramáticamente.
Esta optimización es tan fundamental que reconocer problemas N+1 (usando herramientas como Django Debug Toolbar para detectar conteos excesivos de consultas) y aplicar la solución correcta es una competencia central que distingue a desarrolladores que escriben código Django eficiente de aquellos cuyos apps se ralentizan a medida que los datos crecen.
También está entre los temas de entrevista Django más frecuentemente probados, precisamente porque refleja una comprensión práctica y crítica del rendimiento del ORM.