为什么MongoDB不使用索引交集？

我用一个集合创建了一个数据库，该集合只存储两个字段和一个id的文档：

public class Hamster
{
    public ObjectId Id;
    public string Name;
    public int Age;
}

我还为每个字段创建了一个索引

当我在两个字段上执行查询筛选时，我希望它使用组合两个索引来减少集合扫描并提高性能。事实并非如此。我还没有设法诱导一个索引交叉点

那么，是什么阻止MongoDB应用索引交集呢？

当您使用时，您可以看到优化器考虑使用索引交集，并选择不：

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

如果有足够的复合索引，MongoDB将永远不会选择交集。其他限制可在上找到：

当满足以下条件时，查询优化器可以选择索引交叉点计划： 1.相关集合中的大多数文档都驻留在磁盘上。索引交集的优点是，当交集的大小很小时，它可以避免获取完整的文档。如果文档已经在内存中，那么避免获取就不会有什么好处。 2.查询谓词是单点间隔，而不是范围谓词或一组间隔。单点间隔查询返回按磁盘位置排序的文档，这允许优化器选择以非阻塞方式计算交叉点的计划。这通常比计算交集的另一种模式要快，即用一个索引的结果构建一个哈希表，然后用第二个索引的结果进行探测。 3.要相交的两个指数都不是高选择性的。如果其中一个索引是选择性的，那么优化器将选择一个只扫描该选择性索引的计划。 4.交叉点的大小相对于单个索引解决方案扫描的索引键的数量来说很小。在这种情况下，查询执行器可以使用索引交集查看较小的文档集，这可能使我们能够从磁盘获取较少的数据

MongoDB对交叉口有很多限制，这使得它不太可能被实际使用