Kiedy używasz explain(true) widać, że optymalizator rozważa użycie przecięcia indeksu i postanawia nie:
"cursor" : "BtreeCursor Age", // Chosen plan.
...
"allPlans" : [
{
"cursor" : "BtreeCursor Age",
...
},
{
"cursor" : "BtreeCursor Name",
...
},
{
"cursor" : "Complex Plan", // Index intersection.
...
}
]
MongoDB nigdy nie wybierze przecięcia, jeśli istnieje wystarczający indeks złożony. Inne ograniczenia można znaleźć na bilecie Jira na skrzyżowanie indeksów:
Optymalizator zapytań może wybrać plany przecięcia indeksu, gdy spełnione są następujące warunki:
1. Większość dokumentów w odnośnym zbiorze znajduje się na dysku. Zaletą przecięcia indeksów jest to, że pozwala uniknąć pobierania kompletnych dokumentów, gdy rozmiar przecięcia jest mały. Jeśli dokumenty są już w pamięci, nie ma nic do zyskania unikając pobierania.
2. Predykaty zapytania są interwałami jednopunktowymi, a nie predykatami zakresu lub zestawem interwałów. Zapytania w odstępach jednopunktowych zwracają dokumenty posortowane według lokalizacji na dysku, co pozwala optymalizatorowi wybrać plany obliczające przecięcie w sposób nieblokujący. Jest to generalnie szybsze niż alternatywny tryb obliczania przecięcia, który polega na zbudowaniu tablicy mieszającej z wynikami z jednego indeksu, a następnie sondowaniu jej wynikami z drugiego indeksu.
3. Żaden z przecinanych indeksów nie jest wysoce selektywny. Jeśli jeden z indeksów jest selektywny, optymalizator wybierze plan, który po prostu skanuje ten selektywny indeks.
4. Rozmiar przecięcia jest mały w stosunku do liczby kluczy indeksu skanowanych przez jedno z rozwiązań z jednym indeksem. W tym przypadku executor zapytania może przeglądać mniejszy zestaw dokumentów za pomocą przecięcia indeksów, co potencjalnie pozwala nam czerpać korzyści z mniejszej liczby pobierań z dysku.
MongoDB ma wiele ograniczeń na skrzyżowaniu, co sprawia, że jest mniej prawdopodobne, że będzie faktycznie używany.
