Definición
La consulta N+1 es un patrón de rendimiento en el que un programa hace una consulta para obtener una lista y después una consulta más por cada elemento de esa lista.
De ahí el nombre: 1 consulta inicial + N consultas adicionales.
El ejemplo típico: pides los 200 pedidos del mes, y luego, al pintar cada uno, preguntas por el nombre de su cliente. Total: 201 viajes a la base de datos donde bastaban 2.
Lo que lo hace peligroso no es el coste de cada consulta —cada una es rapidísima—, sino que se paga la ida y vuelta 200 veces. Con una latencia de 2 milisegundos por consulta, eso son 400 milisegundos de espera pura.
Por qué se cuela
Casi siempre por un ORM. Estas herramientas hacen que acceder a un dato relacionado parezca gratis: escribes algo equivalente a «el nombre del cliente de este pedido» y funciona. Lo que no se ve es que cada acceso lanza una consulta.
El código parece limpio. El bucle parece inocente. Y el problema es invisible en el editor.
También aparece sin ORM, en cuanto alguien mete una consulta dentro de un bucle sin pensarlo.
Ejemplo práctico
Un listado de pedidos que en local va instantáneo y en producción tarda ocho segundos es N+1 hasta que se demuestre lo contrario.
Lo que aprendí: la razón de que no se detecte antes es que en desarrollo la base de datos está en la misma máquina y con pocos datos. Con 20 registros y latencia cero, 21 consultas son imperceptibles. Con 2.000 registros y la base de datos en otro servidor, son 2.001 viajes por red y la página se cae de las manos.
Por eso el síntoma característico es tan reconocible: funciona perfecto en pruebas y se degrada progresivamente en producción, empeorando a medida que crecen los datos. Nadie cambió nada; simplemente hay más clientes.
El segundo aprendizaje, sobre cómo se detecta: no se detecta leyendo código, se detecta contando consultas. La medida que lo hace evidente es registrar cuántas consultas se ejecutan por petición. Si una página lanza cientos, ya sabes qué pasa, y normalmente ves el patrón repetido: la misma consulta con distinto identificador, cientos de veces seguidas. Ver observabilidad.
Las tres formas de resolverlo:
Carga anticipada. Decirle al ORM que traiga los datos relacionados de una vez. Es la solución en el 90 % de los casos y suele ser una línea.
Una consulta con unión. Traer todo lo necesario en una sola consulta bien escrita.
Dos consultas y cruzar en memoria. Pide la lista, saca los identificadores únicos, haz una segunda consulta con todos ellos y empareja en el código. Es la solución cuando la unión resulta pesada.
Y una advertencia sobre lo que N+1 no es: no es «hacer muchas consultas» sin más. Es hacer una consulta dentro de un bucle sobre resultados de otra consulta. Ese matiz importa, porque el arreglo consiste siempre en lo mismo: sacar la consulta fuera del bucle y pedir todo de golpe.
Errores comunes
- Consultas dentro de un bucle, con o sin ORM.
- Probar solo con pocos datos.
- No registrar el número de consultas por petición.
- Culpar al servidor y ampliar recursos cuando el problema es el patrón. Más máquina no arregla 2.000 viajes.
- Arreglarlo en un listado y no en los otros seis que tienen el mismo patrón.
- Pasarse con la carga anticipada y traer relaciones que no se usan, cambiando un problema por otro.
- Confundirlo con falta de índices. Son cosas distintas y a veces coinciden.
Cuándo revisarlo
Al construir cualquier listado que muestre datos relacionados, y siempre que una página se vuelva lenta al crecer los datos.
La comprobación definitiva: cuenta las consultas de una página. Si el número sube cuando suben las filas mostradas, tienes un N+1 — y su arreglo suele ser la mejora de rendimiento más grande y más barata de todo el sistema.
