Interseção de índices versus índices compostos

Interseção de índices é a capacidade do MongoDB de usar simultaneamente dois ou mais índices de campo único para atender a uma única consulta. Em vez de criar um índice composto que cubra todos os campos do filtro, o MongoDB examina vários índices de forma independente e depois obtém a interseção dos IDs dos documentos correspondentes. Parece conveniente, mas, na prática, raramente é tão rápido quanto um índice composto bem projetado.

Quando o MongoDB considera a interseção de índices, o planejador de consultas: 1) Examina o índice A em busca de documentos que correspondam à condição 1 e coleta seus IDs de registro. 2) Examina o índice B em busca de documentos que correspondam à condição 2. 3) Calcula a interseção dos dois conjuntos de IDs. 4) Busca os documentos reais usando esses IDs. Isso é chamado de etapa AND_SORTED ou AND_HASH na saída de explain().

O MongoDB usa a interseção de índices somente quando o planejador de consultas calcula que ela é mais barata que as alternativas. O planejador executa em paralelo até 200 planos candidatos (usando execução de teste) e escolhe aquele com o menor custo estimado. A interseção tem mais probabilidade de ser escolhida quando a coleção é grande e cada índice individual é altamente seletivo — ambos restringem drasticamente o conjunto de candidatos antes da etapa de interseção.

Um índice composto armazena chaves de vários campos em uma única árvore B previamente ordenada. Uma consulta nesses campos faz uma única varredura eficiente do índice e retorna os documentos em ordem. A interseção de índices faz várias varreduras separadas e depois mescla os resultados na memória. A etapa de mesclagem adiciona sobrecarga de CPU e memória que um índice composto evita completamente.

A interseção de índices não pode atender a uma ordenação — o conjunto de resultados mesclado não está em uma ordem específica em relação à chave de ordenação, portanto o MongoDB precisa executar uma etapa SORT em memória. Um índice composto que inclua o campo de ordenação entrega os resultados diretamente na ordem correta, evitando completamente a sobrecarga da ordenação. Para consultas que filtram e ordenam, um índice composto quase sempre é superior.

A interseção de índices ocasionalmente supera um índice composto quando: 1) Ambos os índices individuais são altamente seletivos (cada um retorna pouquíssimos documentos). 2) A consulta é ad hoc — não é possível prever quais campos serão filtrados em conjunto, portanto criar um índice composto para cada combinação seria impraticável. 3) A coleção recebe muitas escritas — menos índices significam menor sobrecarga de escrita, então usar a interseção de dois índices existentes evita adicionar um terceiro.

Você pode forçar o MongoDB a usar um índice específico (ou uma estratégia de interseção) com .hint(). Isso ignora a seleção automática do planejador e é útil para comparações de desempenho — você pode comparar as estatísticas de execução do índice composto escolhido manualmente com o que o planejador faria usando índices individuais.

Quando o MongoDB usa a interseção de índices, a saída de explain() mostra uma etapa AND_SORTED ou AND_HASH como predecessora de duas etapas IXSCAN. AND_SORTED é usada quando ambos os índices retornam resultados na mesma ordem; AND_HASH cria na memória uma tabela de dispersão de um conjunto de resultados e consulta essa tabela com o outro. Ambos são sinais de que um índice composto bem escolhido poderia ser mais rápido.

Para padrões de consulta conhecidos e repetidos, um índice composto quase sempre é mais rápido do que depender da interseção. Os únicos motivos para preferir a interseção são: as consultas são imprevisíveis demais para serem cobertas por índices compostos ou o volume de escrita é tão alto que adicionar mais índices seria muito dispendioso. Nesses casos, mantenha os índices individuais enxutos e permita que o planejador faça a interseção quando isso ajudar.

À medida que as aplicações evoluem, os desenvolvedores adicionam índices de forma reativa. Com o tempo, as coleções acumulam índices redundantes que tornam as escritas mais lentas sem beneficiar as leituras. Faça revisões regulares usando $indexStats: qualquer índice com zero accesses.ops durante um longo período não é usado e pode ser removido. Procure também índices que se tornaram redundantes devido à regra do prefixo de índices compostos.

Use esta estrutura: O padrão de consulta é conhecido e repetido? → Crie um índice composto usando ESR. A consulta é ad hoc ou difícil de prever? → Dependa de índices individuais e aceite a possibilidade de interseção. O volume de escrita é crítico? → Minimize o número total de índices; remova os índices não utilizados. A consulta envolve uma ordenação? → Use sempre um índice composto; a interseção nunca atende a ordenações.

Nesta lição, aprendeu que: a interseção de índices usa dois índices de campo único e mescla os resultados na memória, adicionando sobrecarga, os índices compostos quase sempre são mais rápidos para padrões de consulta conhecidos e repetidos — especialmente os que incluem ordenações e deve usar $indexStats para encontrar e remover índices não utilizados ou redundantes que tornam as gravações mais lentas. A seguir, exploraremos dicas para otimizar pipelines de agregação.