Dada uma consulta padrão simples (sem limit() ou sort() ou qualquer coisa extravagante aplicada) que tenha uma condição de filtro em dois campos (como em name e age no seu exemplo), para encontrar os documentos resultantes, o MongoDB irá:

1. faça uma verificação completa da coleção (leia todos os documentos da coleção inteira, analise o BSON, encontre os valores em questão, teste-os em relação à entrada e retorne/descarte cada documento):Isso é super intenso em E/S e, portanto, lento.
2. usar um índice que contém um dos campos (use a árvore de índice para localizar o subconjunto relevante de documentos seguido por uma varredura deles):Dependendo da sua distribuição de dados/seletividade do índice, isso pode ser muito rápido ou fornecer quase nenhum benefício (imagine um índice em age em um conjunto de dados de milhões de pessoas entre 30 e 40 anos --> cada pesquisa ainda renderia um número infinito de documentos).
3. usar dois índices que juntos contêm os dois campos em questão (carregue os dois índices, execute pesquisas de chave e, em seguida, calcule a interseção dos resultados):Novamente, dependendo da distribuição de seus dados, isso pode ou não proporcionar um ótimo desempenho. Deve, no entanto, na maioria dos casos ser mais rápido do que #2. No entanto, ficaria surpreso se fosse realmente 10 vezes mais lento que o nº 4 (como você mencionou).
4. usar um índice composto (duas pesquisas de chave subsequentes levam imediatamente aos documentos necessários):Esta será a opção mais rápida de todas, pois requer as operações mínimas e mais baratas para obter os documentos corretos. Para garantir o maior nível de reutilização (não o desempenho que não será afetado por isso), você deve geralmente começar com o campo mais seletivo primeiro, então no seu caso provavelmente name e não age dado que muitas pessoas terão a mesma age (tão baixa seletividade) em comparação com name (maior seletividade). Mas essa escolha também depende do seu cenário concreto e das consultas que você pretende executar em seu banco de dados. Há um artigo muito bom na web sobre como definir melhor um índice composto levando em consideração vários aspectos de sua situação específica:https://emptysqua.re/blog/optimizing-mongodb-compound-indexes

Outros aspectos a serem considerados são:As atualizações do índice têm um determinado preço. No entanto, se tudo o que importa é a velocidade de leitura bruta e você tem apenas algumas atualizações de vez em quando, então você deve ir para índices mais/maiores.

E por último, mas não menos importante (!) o conselho de linha de fundo muito usado:crie um perfil do seu sistema usando dados reais e talvez até cenários de carga realistas. E também continue medindo à medida que seus dados/sistema mudam ao longo do tempo.

Leituras adicionais:https://docs.mongodb.com/manual/core/query-optimization/index.html

https://dba.stackexchange.com/questions/158240/mongodb-index-intersection-does-not-eliminate-the-need-for-creating-compound-in

Interseção de índice versus índice composto?

índice composto do mongodb vs. interseção do índice

Como a ordem dos índices compostos importa no MongoDB em termos de desempenho?

No MongoDB, estou usando uma consulta grande, como criarei índice composto ou índice único, então meu tempo de resposta aumenta