explain(true)を使用する場合 オプティマイザがインデックス交差の使用を検討し、次のことを選択しないことがわかります。
"cursor" : "BtreeCursor Age", // Chosen plan.
...
"allPlans" : [
{
"cursor" : "BtreeCursor Age",
...
},
{
"cursor" : "BtreeCursor Name",
...
},
{
"cursor" : "Complex Plan", // Index intersection.
...
}
]
MongoDB 十分な複合インデックスがある場合、交差を選択することはありません。その他の制限は、インデックス交差点のJiraチケットに記載されています：
クエリオプティマイザは、次の条件が満たされる場合にインデックス交差プランを選択できます。
1。関連するコレクションのほとんどのドキュメントはディスクに常駐しています。インデックス交差の利点は、交差のサイズが小さい場合に完全なドキュメントをフェッチすることを回避できることです。ドキュメントがすでにメモリ内にある場合、フェッチを回避しても何も得られません。
2。クエリ述語は、範囲述語または一連の間隔ではなく、単一のポイント間隔です。シングルポイント間隔でのクエリは、ディスクの場所でソートされたドキュメントを返します。これにより、オプティマイザは、非ブロッキング方式で交差を計算するプランを選択できます。これは一般に、交差点を計算する代替モードよりも高速です。つまり、1つのインデックスの結果を使用してハッシュテーブルを作成し、2番目のインデックスの結果を使用してそれをプローブします。
3。交差するインデックスはどちらも高度に選択的ではありません。インデックスの1つが選択的である場合、オプティマイザーはこの選択的インデックスをスキャンするだけのプランを選択します。
4。交差点のサイズは、いずれかの単一インデックスソリューションによってスキャンされたインデックスキーの数に比べて小さいです。この場合、クエリエグゼキュータはインデックスの共通部分を使用して少数のドキュメントセットを参照できるため、ディスクからのフェッチが少ないというメリットを享受できる可能性があります。
MongoDB 交差点には多くの制限があり、実際に使用される可能性は低くなります。