O que é o problema de consultas N+1?

O problema de consultas N+1 é um padrão em que buscar N registros dispara uma query extra por registro — N+1 idas ao banco em vez de uma ou duas. É o bug sério de performance mais comum em aplicações apoiadas em dados, e o mais camuflado: cada query individual é rápida, o código lê perfeitamente, e a página funciona — até o dia em que os volumes reais de dados chegam.

Principais pontos

O bug, às claras

// 1 query: busca 100 posts
const posts = await postRepo.findRecent(100);

for (const post of posts) {
  // +1 query POR POST — post.author parece uma propriedade,
  // mas o lazy loading roda: SELECT * FROM users WHERE id = ?
  render(post.title, (await post.author).name);
}
// Log de queries: 1 + 100 = 101 idas ao banco para renderizar uma página

A correção, como os SDKs a expressam — declare a relação de antemão, e a plataforma a busca na mesma requisição:

// JavaScript / Node.js — Back4app JS SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
const query = new Parse.Query('Comment');
query.equalTo('post', post);
query.include('author');                    // eager-load the pointer
const comments = await query.find();        // one round trip, total

comments.forEach((c) =>
  render(c.get('text'), c.get('author').get('username')) // already loaded
);

// Flutter / Dart — Back4app Flutter SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
final query = QueryBuilder<ParseObject>(ParseObject('Comment'))
  ..whereEqualTo('post', post.toPointer())
  ..includeObject(['author']);              // eager-load the pointer
final response = await query.query();       // one round trip, total

// iOS / Swift — Back4app Swift SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
let query = Comment.query("post" == post)
  .include("author")                        // eager-load the pointer
query.find { result in
  if case .success(let comments) = result { // one round trip, total
    comments.forEach { render($0.text, $0.author?.username) }
  }
}

// Android / Kotlin — Back4app Android SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
val query = ParseQuery.getQuery<ParseObject>("Comment")
query.whereEqualTo("post", post)
query.include("author")                     // eager-load the pointer
query.findInBackground { comments, e ->     // one round trip, total
  if (e == null) comments.forEach {
    render(it.getString("text"), it.getParseObject("author")?.getString("username"))
  }
}

O custo, na ponta do lápis

A aritmética que os explicadores pulam — tempo total ≈ query da lista + (N × latência de ida e volta):

Correções publicadas batem com a matemática: páginas caindo de 1,4 s para 0,16 s, endpoints acelerando 30× ou mais. Dois corolários que valem fixar: paginação limita N — um tamanho de página limitado limita o raio da explosão antes mesmo da correção de verdade; e a versão em rede é pior — quando cada uma das N chamadas é uma requisição HTTP em vez de uma query local, multiplique por dezenas de milissegundos em vez de um dígito.

As quatro saídas

A última linha é o caso famoso do GraphQL: resolvers disparam por objeto pai, recriando o loop no servidor, e o padrão loader — coletar chaves num tick, buscar uma vez, memoizar por requisição — é a cura padrão da indústria. Uma regra sutil vem junto: loaders têm escopo de requisição; um global vira um cache velho com bugs de autorização.

Detecção: cace as queries rápidas

A assinatura do N+1 é o inverso do trabalho normal de performance: você procura muitas queries rápidas e idênticas, não uma lenta — motivo pelo qual logs de queries lentas, a ferramenta usual, nunca a veem. Os métodos que veem: log de debug do ORM (a mesma instrução, N parâmetros diferentes, uma renderização); as visões de spans do APM, onde a cascata de spans curtos idênticos é inconfundível; e o mais barato de todos — conte as queries de um carregamento de página em desenvolvimento, com um limiar na cabeça: uma página de lista deve custar queries em um dígito, não em múltiplos das suas linhas. O gêmeo do lado da escrita merece a mesma auditoria: um loop de insert por item é o N+1 das escritas, corrigido com operações em bulk.

Casos de uso comuns

• Listas com autores, donos ou status — o lar canônico: todo feed, inbox e tabela que junta pessoas a itens.
• APIs GraphQL — campos de lista aninhados são estruturalmente N+1 até existirem loaders.
• Bancos de documentos — um find por documento referenciado; corrigido com include, IN em batch ou embutindo, conforme as regras de modelagem.
• Fan-outs de microsserviços — uma lista do serviço A, uma chamada HTTP ao serviço B por item; endpoints compostos e BFFs existem para acabar com isso.
• Jobs em background — o loop que processa 10.000 registros com duas queries cada, custando horas em silêncio.

Lazy vs. eager loading: matriz de decisão

E a regra de auditoria permanente que sobrevive a qualquer matriz: toda relação tocada dentro de um loop é culpada até o log de queries provar o contrário.

Limitações e trade-offs

• Eager loading pode corrigir demais. Incluir relações pesadas em todo lugar troca N+1 por payloads inchados e joins largos — inclua o que a tela renderiza, não o grafo inteiro.
• Joins têm seu próprio penhasco. Joins um-para-muitos duplicam as linhas do pai por filho; com fan-out alto, a busca em batch de duas queries vence o join único.
• Loaders adicionam maquinário. Escopo por requisição, invalidação de cache dentro da requisição e janelas de batching são código de verdade — o preço do batch automático.
• Frameworks o reintroduzem em silêncio. Serializers, helpers de template e reviews de “só mais um campo” são como páginas corrigidas regridem; a checagem de contagem de queries pertence ao CI, não à memória.
• A correção é por caminho, não global. N+1 é um bug de padrão de acesso; cada tela nova refaz a pergunta.

O N+1 no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Seus SDKs fazem da correção o idioma, não a remediação: relações são Pointers tipados, e o include() — as abas de código acima — as busca na mesma requisição, agrupadas no servidor. A API GraphQL resolve queries aninhadas sem fan-out por campo, e os padrões de paginação limitam N antes de ele criar dentes. O loop que causa o N+1 não tem forma natural de ser escrito — que é o melhor tipo de correção: a que ninguém precisa lembrar.