Consultas N+1: detectarlas contando y corregirlas con batching

Qué es

El código carga con una consulta una lista de N filas padre y después lee, en cada fila, una relación de carga perezosa (lazy); el ORM emite una consulta adicional por fila. La documentación de SQLAlchemy lo describe así: para cualquier conjunto de N objetos cargados, acceder a sus atributos de carga perezosa implica que se emitirán N+1 sentencias SELECT. La misma forma aparece sin ORM: un bucle que llama a una API HTTP por cada elemento, un resolver de GraphQL que consulta por cada nodo, una búsqueda en cache por cada clave.

Por qué importa

Cada consulta cuesta un viaje de ida y vuelta (round trip) por poco que devuelva. Una página de 200 filas se convierte en 201 viajes; el coste escala con los datos, no con el código, de modo que el problema es invisible con un fixture de prueba de tres filas y solo aparece en producción. Los logs de consultas lentas tampoco lo muestran, porque cada una de las N consultas es rápida.

Cómo aplicarlo

• Detectar contando. Verifica en las pruebas el número de consultas por petición (assertNumQueries de Django, que comprueba que una llamada ejecuta un número dado de consultas; un event listener del engine en SQLAlchemy; un contador por petición en el logger de consultas) y haz que fallen cuando el número dependa del tamaño del resultado: ejecuta la misma petición con 1 fila y con 50 filas y compara.
• Hacer que las cargas perezosas no deseadas fallen de forma visible. raiseload() de SQLAlchemy sustituye la carga perezosa por una excepción, de modo que un nuevo acceso a un atributo en una plantilla o un serializador sale a la luz en las pruebas y no como N+1 en producción.
• Corregir las relaciones to-one con un join: select_related() en Django, joinedload() en SQLAlchemy. Una sola consulta, con filas más anchas.
• Corregir las colecciones con una segunda consulta basada en IN (ids): prefetch_related() en Django, selectinload() en SQLAlchemy, que su documentación prefiere frente a la antigua carga mediante subconsulta. Dos consultas en lugar de N+1, sin multiplicación de filas.
• Fuera de los ORM, se aplica la misma idea: reunir primero las claves, obtenerlas en una sola llamada y luego asignar los resultados a los elementos (el patrón DataLoader); para las APIs remotas, usar endpoints por lotes o concurrencia acotada.
• La guía de optimización de Django recomienda entender cuándo se evalúan los querysets y qué atributos se guardan en cache, y aplicar select_related() y prefetch_related() donde haga falta, posiblemente en los managers, con la salvedad de que el acceso a objetos relacionados usa el manager base y no el predeterminado.

Trampas

Hacer un join con una colección repite la fila padre por cada hijo y puede resultar más lento que dos consultas. Precargarlo todo desperdicia memoria en campos que nadie lee. Una lista IN con decenas de miles de ids requiere dividirse en lotes (chunking). El número de consultas es una propiedad de la ruta de código, no del modelo: un atributo adicional en un serializador reintroduce el N+1, y por eso la verificación del número de consultas debe permanecer siempre en la suite de pruebas.