Когато използвате explain(true) можете да видите, че оптимизаторът обмисля използването на пресичане на индекси и избира да не:
"cursor" : "BtreeCursor Age", // Chosen plan.
...
"allPlans" : [
{
"cursor" : "BtreeCursor Age",
...
},
{
"cursor" : "BtreeCursor Name",
...
},
{
"cursor" : "Complex Plan", // Index intersection.
...
}
]
MongoDB никога няма да избере пресичане, ако има достатъчен сложен индекс. Други ограничения можете да намерите в билета на Jira за Index Intersection:
Оптимизаторът на заявки може да избере планове за пресичане на индекси, когато са изпълнени следните условия:
1. Повечето от документите в съответната колекция са резидентни на диск. Предимството на индексното пресичане е, че може да избегне извличането на пълни документи, когато размерът на пресечната точка е малък. Ако документите вече са в паметта, няма какво да спечелите, като избягвате извличанията.
2. Предикатите на заявката са интервали от една точка, а не предикати на диапазон или набор от интервали. Заявките през интервали от една точка връщат документи, сортирани по местоположение на диска, което позволява на оптимизатора да избере планове, които изчисляват пресечната точка по неблокиращ начин. Това обикновено е по-бързо от алтернативния режим на изчисляване на пресечната точка, който е да се изгради хеш таблица с резултатите от един индекс и след това да се изследва с резултатите от втория индекс.
3. Нито един от индексите, които трябва да бъдат пресечени, не е силно селективен. Ако един от индексите е селективен, тогава оптимизаторът ще избере план, който просто сканира този селективен индекс.
4. Размерът на пресечната точка е малък в сравнение с броя на индексните ключове, сканирани от едното решение с един индекс. В този случай изпълнителят на заявка може да разглежда по-малък набор от документи, използвайки пресичане на индекси, което потенциално ни позволява да се възползваме от по-малко извличания от диск.
MongoDB има много ограничения за пресичане, което прави по-малко вероятно да бъде действително използвано.
