Consultas N+1: o vilão silencioso da API lenta

A rota funcionava bem com 10 pedidos no ambiente de teste. Em produção, com 300, demora quatro segundos. O código parece inocente — e é exatamente por isso que o problema N+1 é tão comum.

Como ele aparece

const pedidos = await db.pedido.findMany()
for (const p of pedidos) {
  p.cliente = await db.cliente.findUnique({ where: { id: p.clienteId } })
}

Uma consulta para a lista (1) e uma para cada item (N). Cada ida ao banco custa poucos milissegundos — multiplicados por centenas, viram segundos.

Como corrigir

• Junte numa consulta: JOIN no SQL ou include no ORM.
• Busque em lote: colete os ids e faça uma única consulta com WHERE id IN (...).
• DataLoader em APIs GraphQL, onde o N+1 é ainda mais traiçoeiro (GraphQL ou REST: escolha pelo problema, não pela moda).

const pedidos = await db.pedido.findMany({ include: { cliente: true } })

Como descobrir

Ative o log de consultas em desenvolvimento e conte quantas uma rota dispara. Ferramentas de observabilidade em produção mostram o mesmo padrão: dezenas de consultas idênticas em sequência (Observabilidade para quem não é SRE: métricas, logs e traces).

Os parentes do N+1

Mesmo com uma consulta só, a rota pode estar lenta por falta de índice (Índices no banco de dados: a otimização mais barata que você ainda não fez) ou por trazer dados demais sem paginação (Paginação por cursor vs. offset: quando a lista começa a ficar lenta).

A We Codex otimiza backends lentos em sistemas web e Performance WPO. Fale com a gente.