MongoDB: índices e explain para consultas previsíveis

Resposta rápida

Um índice deve refletir a consulta que o sistema realmente executa. Rode a consulta em dados representativos com explain("executionStats"), observe nReturned, totalDocsExamined e totalKeysExamined, crie um candidato e compare. Não escolha índice apenas porque um campo parece importante.

Comece pelo padrão de acesso

Liste filtros, ordenações e limites. Uma consulta que filtra tenant_id e ordena por created_at pode precisar de uma chave composta nessa ordem, mas a decisão depende de cardinalidade e de outros padrões. Índices extras ocupam memória e aumentam custo de escrita.

Meça o plano atual

db.orders.find({tenant_id: "t1", status: "open"})
  .sort({created_at: -1})
  .limit(20)
  .explain("executionStats")

Use dados fictícios em homologação. Compare quantidade retornada e examinada, estágio do plano e tempo. Um plano em coleção pequena pode esconder o problema que aparece quando o volume cresce.

Teste um índice candidato

db.orders.createIndex({tenant_id: 1, status: 1, created_at: -1})

Repita o explain e compare. O índice não é automaticamente melhor para todas as consultas. Examine também os padrões de escrita e a memória disponível.

Evite conclusões falsas

Um resultado rápido pode vir do cache; uma consulta lenta pode estar concorrendo com carga de produção. COLLSCAN nem sempre é erro em coleção minúscula, e IXSCAN não garante que o índice seja seletivo. Faça testes com volume, distribuição e filtro próximos do real.

Operação segura

Crie índices em janela controlada e observe impacto. Em réplicas e versões específicas, valide o procedimento de construção. Remova índice sem uso somente após período de observação e revisão das consultas. Nunca elimine um índice da produção por uma única amostra.

Mantenha a decisão vinculada a uma consulta identificada e a uma janela de observação.

Isso facilita revisar a alteração quando o esquema ou o padrão de tráfego mudar.

Também registre o responsável.

Para manter banco e aplicação com margem, conheça os planos de VPS e monitore I/O, memória e espaço.

Checklist

• [ ] Padrão de acesso documentado.
• [ ] Dados representativos usados.
• [ ] Explain antes e depois registrado.
• [ ] Custo de escrita e memória avaliado.
• [ ] Remoção baseada em período de observação.

FAQ

Mais índices sempre melhoram a leitura?

Não. Eles podem aumentar custo de escrita, uso de memória e complexidade.

Posso confiar só no executionTimeMillis?

Não. Observe plano, documentos/chaves examinados, cache, concorrência e distribuição.

Custo que fica escondido

Todo índice precisa ser mantido durante inserções e atualizações. Em uma coleção com alta escrita, adicionar um índice para uma consulta rara pode piorar o sistema geral. Avalie tamanho, seletividade e frequência do padrão. Se a consulta inclui vários tenants, confirme que o índice não permite que uma empresa atravesse o escopo de outra; performance e isolamento de dados devem ser revisados juntos.