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

考虑下面的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
                }
            ]
        ]
    }
}

这里的问题是 它清楚地表明查询完全在索引上运行（如

“indexOnly”：true

）。 但是为什么“扫描者”是真的
根据Btree索引模型，c位于索引的尾部，因此可以利用它进行排序。没有

---

为什么不使用它？

如果使用以下索引扫描，则顺序将为false

db.collec.ensureIndex（{a:1，c:-1，b:1}）

这是正确的，也是正确的

至于原因：索引本质上类似于此树：

• A:“价值A”
  • B:“ABC”
    • C:435
    • C:678
  • B:“BCD”
    • C:123
    • C:993

如您所见，排序是正确的，并且是递增的，但是如果您将

c

的值按顺序取，而不限于固定

b

的子集，您将得到

[435678123993]

，这是不正确的，因此需要

扫描和排序器

不幸的是，没有索引的索引非常不灵活。
是的，我接受这一点。但是索引并不是专门用于这个查询的，它已经存在了，我第一次做这个查询。仅供参考，更改索引会影响已取决于索引的查询。我的问题是，为什么它不能使用索引进行排序，即使c位于索引的末尾？最好补充一点：它得到的宣传越多，mongodb inc可能就越有可能实现它——这一点很好！我在答案中添加了链接，因为很多人可能不知道这个词，即使他们知道这个功能。