Når du bruger explain(true) du kan se, at optimeringsværktøjet overvejer at bruge indekskryds og vælger ikke at:
"cursor" : "BtreeCursor Age", // Chosen plan.
...
"allPlans" : [
{
"cursor" : "BtreeCursor Age",
...
},
{
"cursor" : "BtreeCursor Name",
...
},
{
"cursor" : "Complex Plan", // Index intersection.
...
}
]
MongoDB vil aldrig vælge kryds, hvis der er et tilstrækkeligt sammensat indeks. Andre begrænsninger kan findes på Jira-billetten til Index Intersection:
Forespørgselsoptimeringsværktøjet kan vælge indekskrydsningsplaner, når følgende betingelser gælder:
1. De fleste af dokumenterne i den relevante samling er diskresidente. Fordelen ved indekskryds er, at det kan undgå at hente komplette dokumenter, når krydsets størrelse er lille. Hvis dokumenterne allerede er i hukommelsen, er der intet at vinde ved at undgå hentning.
2. Forespørgselsprædikaterne er enkeltpunktsintervaller snarere end intervalprædikater eller et sæt intervaller. Forespørgsler over enkeltpunktsintervaller returnerer dokumenter sorteret efter diskplacering, hvilket gør det muligt for optimeringsværktøjet at vælge planer, der beregner krydset på en ikke-blokerende måde. Dette er generelt hurtigere end den alternative metode til at beregne skæringspunktet, som er at bygge en hash-tabel med resultaterne fra det ene indeks og derefter undersøge det med resultaterne fra det andet indeks.
3. Ingen af de indekser, der skal gennemskæres, er meget selektive. Hvis et af indekserne er selektivt, vil optimeringsværktøjet vælge en plan, som blot scanner dette selektive indeks.
4. Størrelsen af krydset er lille i forhold til antallet af indeksnøgler, der scannes af hver enkelt indeksløsning. I dette tilfælde kan forespørgselsudøveren se på et mindre sæt dokumenter ved hjælp af indekskryds, hvilket potentielt giver os mulighed for at høste fordelene ved færre hentning fra disken.
MongoDB har mange begrænsninger på kryds, hvilket gør det mindre sandsynligt, at det faktisk bliver brugt.