MongoDB: índices e explain para consultas previsíveis

--- queue_position: 33 title: "MongoDB: índices e explain para consultas previsíveis" slug: mongodb-indices-explain-consultas-previsiveis site_key: host-yousecure canonical: https://yousecure.io/blog/mongodb-indices-explain-consultas-previsiveis category: databases cluster: mongodb-performance search_intent: informacional-pratica funnel_stage: meio author: "Host You Secure Team" created_at: "2026-09-09T11:29:43-03:00" planned_scheduled_at: null status: queued-review meta_description: "Use índices e explain no MongoDB para investigar consultas, comparar keysExamined e evitar otimização baseada em suposição." excerpt: "Índice bom acompanha o padrão real de filtro, ordenação e cardinalidade; `explain` mostra se ele está sendo usado." quick_answer: "Reproduza a consulta real com dados representativos, rode `explain('executionStats')`, compare documentos e chaves examinados e só então crie ou ajuste um índice." featured_image: images/33-mongodb-explain.png featured_image_alt: "Árvore de índice acelerando uma consulta em documentos MongoDB" tags: [mongodb, indices, explain, banco-de-dados, performance] evidence_type: reproducible_procedure evidence_environment: MongoDB em ambiente de teste com coleção e volume representativos evidence_procedure: "Rodar consulta com explain, criar índice candidato, repetir e comparar estatísticas." evidence_observed_result: "A comparação antes/depois mostra se o índice reduziu o trabalho da consulta." evidence_limitation: "Planos podem variar com cache, distribuição dos dados, versão e concorrência." information_gain: "Ensina a medir o custo e o impacto de índice, incluindo o custo de escrita e memória." primary_cta: "Ver planos de VPS" landing: /hosting_vps --- # 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 ```javascript 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 ```javascript 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](https://yousecure.io/hosting_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.