¿Qué es el problema de las consultas N más uno y cómo se arregla?

Ejecutas una consulta para traer una lista, luego recorres las filas y lanzas otra consulta por fila, así que 200 publicaciones se convierten en 201 viajes de ida y vuelta. Se arregla cargando las filas relacionadas en una sola pasada: un join, una consulta IN indexada por id del padre, o un cargador con batching que recoge ids dentro de un mismo tick de la petición. La pista es que la latencia escala de forma lineal con el número de resultados mientras cada consulta individual parece rápida.

Suele aparecer en cuanto alguien renderiza una lista. Traes pedidos y luego en la plantilla tocas order.customer.name, y el ORM lanza en silencio una consulta por fila. Individualmente son medio milisegundo, así que nada parece roto hasta que la lista crece y el endpoint tarda cuatro segundos. Lo detecto mirando el número de consultas por petición en vez de su duración; la mayoría de herramientas de APM lo muestran directamente, y en local activo el log de consultas y cuento. La solución depende de la forma. Para una relación simple de pertenencia, una carga anticipada o un join va bien. Para una relación de uno a muchos donde un join multiplicaría filas, prefiero una segunda consulta con una cláusula IN y coser en memoria. En una API de GraphQL tiene que ser un dataloader, porque los resolvers no tienen ni idea de que se les está llamando en lote. Lo que evito es cargar todo de forma anticipada por defecto, ya que eso cambia un problema por traerse media base de datos a memoria.