为什么MongoDB不能使用与查询非常相似(不精确)的复合索引？

Question

考虑下面的Mongo索引策略和查询,

指数:

db.collec.ensureIndex({a:1,b:1,c:1});

查询:

db.collec.find({"a":"valueA"},{"_id":0,"a":1,"c":1}).sort({"c":-1}).limit(150)

上述查询的解释返回:

/* 0 */
{
    "cursor" : "BtreeCursor a_1_b_1_c_1",
    "isMultiKey" : false,
    "n" : 150,
    "nscannedObjects" : 178,
    "nscanned" : 178,
    "nscannedObjectsAllPlans" : 279,
    "nscannedAllPlans" : 279,
    "scanAndOrder" : true,
    "indexOnly" : true,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 1,
    "indexBounds" : {
        "a" : [ 
            [ 
                "valueA", 
                "valueA"
            ]
        ],
        "b" : [ 
            [ 
                {
                    "$minElement" : 1
                }, 
                {
                    "$maxElement" : 1
                }
            ]
        ],
        "c" : [ 
            [ 
                {
                    "$minElement" : 1
                }, 
                {
                    "$maxElement" : 1
                }
            ]
        ]
    }
}

这里的问题是它清楚地表明查询完全在Index(as "indexOnly" : true)上运行.但是为什么"scanAndOrder" : true
根据Btree索引模型,c位于索引的尾部,所以它可以用来排序.没有？

为什么不用？

Answer 1

这是正确的,也有记录.

至于原因:索引看起来基本上像这棵树:

• 答:"价值A"
  • B:"ABC"
    • C:435
    • C:678
  • B:"BCD"
    • C:123
    • C:993

正如您所看到的,排序是正确的并且是升序的,但是如果您采用c有序值而不限制为固定的子集b,那么您将得到[435, 678, 123, 993],这是不正确的,因此scanAndOrder是必需的.

不幸的是,没有索引交叉的索引非常不灵活.