Em geral, você desejará colocar um índice nos campos mais usados ​​como critérios de filtro em suas consultas mais importantes/frequentes, começando com os campos mais seletivos primeiro. Há algumas orientações decentes sobre o tópico como parte da documentação do MongoDB . Uma declaração de interesse particular para o seu caso é provavelmente esta, pois você tem muito $or s:

O mais importante aqui, no entanto, é medir, medir, medir e analisar os planos de execução de consultas usando explicar() . A razão é que provavelmente você terá diferentes tipos de consultas que seu aplicativo precisa suportar e precisará fazer uma troca em algum ponto em que terá que escolher entre os custos de manutenção do índice (por exemplo, bloqueios de gravação durante atualizações de índice e requisitos de espaço em disco) e a solução teoricamente mais rápida em que todos os campos usados ​​em uma única consulta são cobertos por um único índice.

Todo esse tópico de indexação é um pouco confuso que depende muito do seu cenário preciso:

• Seus dados são altamente atualizados e as gravações precisam ser super-rápidas (você deseja índices menores/menores) ou seus dados são bastante estáveis ​​com leituras frequentes que precisam ser rápidas (vá com índices mais/maiores)?
• Que tipos de consultas você precisa oferecer suporte? Quão semelhantes eles são em termos de seus filtros? Certas combinações de filtros serão mais prováveis ​​do que outras? Quais consultas precisam ter um bom desempenho, quais podem ser um pouco mais lentas?
• Como os dados em seus campos potencialmente indexados são distribuídos?
• e assim por diante...

Você não encontrará o índice único que ajuda todas as suas consultas a ter o melhor desempenho. E também, ao adicionar mais índices ou alterar os existentes, isso pode fazer com que o otimizador de consultas pare de usar algum índice para algumas consultas e escolha um plano de execução diferente, que pode ou não ser desejado. Portanto, meça tudo o que é importante em qualquer alteração em sua indexação ou layout de dados físicos (configuração de hardware, fragmentação...). Por fim, você deve medir o desempenho de sua consulta regularmente à medida que sua quantidade de dados aumenta, a menos que seja previsivelmente uniforme em sua distribuição.

Para encurtar a história:Escolha uma abordagem iterativa e comece adicionando um índice (sugiro adicionar um em isBlockedByAdmin , isDelete e information.shares.userId ) então meça o desempenho de sua consulta e refine seu índice com base em suas descobertas (e novamente, e novamente, ...).