Varför använder inte MongoDB index-korsning?

När du använder explain(true) du kan se att optimeraren överväger att använda indexskärning och väljer att inte:

"cursor" : "BtreeCursor Age", // Chosen plan.
...
"allPlans" : [
   {
       "cursor" : "BtreeCursor Age",
       ...
   },
   {
       "cursor" : "BtreeCursor Name",
       ...
   },
   {
       "cursor" : "Complex Plan", // Index intersection.
       ...
   }
]

MongoDB kommer aldrig att välja korsning om det finns ett tillräckligt sammansatt index. Andra begränsningar finns på Jira-biljetten för Index Intersection:

Frågeoptimeraren kan välja indexkorsningsplaner när följande villkor gäller:
1. De flesta av dokumenten i den relevanta samlingen är diskresidenta. Fördelen med indexkorsning är att den kan undvika att hämta kompletta dokument när korsningen är liten. Om dokumenten redan finns i minnet finns det inget att vinna på att undvika hämtningar.
2. Frågepredikaten är enpunktsintervall snarare än intervallpredikat eller en uppsättning intervall. Frågor över enpunktsintervall returnerar dokument sorterade efter diskplats, vilket gör att optimeraren kan välja planer som beräknar korsningen på ett icke-blockerande sätt. Detta är i allmänhet snabbare än det alternativa sättet att beräkna skärningspunkten, vilket är att bygga en hashtabell med resultaten från ett index och sedan undersöka den med resultaten från det andra indexet.
3. Inget av indexen som ska skäras är särskilt selektiva. Om ett av indexen är selektivt kommer optimeraren att välja en plan som helt enkelt skannar detta selektiva index.
4. Storleken på skärningspunkten är liten i förhållande till antalet indexnycklar som skannas av endera enkelindexlösningen. I det här fallet kan frågeexekutorn titta på en mindre uppsättning dokument med hjälp av indexskärning, vilket potentiellt tillåter oss att dra nytta av färre hämtningar från disken.

MongoDB har många begränsningar för korsningen vilket gör det mindre sannolikt att det faktiskt används.