Question

我有一个查询

php app/console doctrine:schema:update --force

解释我发现它使用索引db.Product.find({ CategoryPath: /^399-305-352(-\d+)*$/, "Availability.Status": { $lt: 4 }, $or: [{ _id: { $lt: 331000000 } }, { _id: { $gt: 852000000, $lt: 853000000 } }, { _id: { $gt: 972000000, $lt: 973000000 } }] }).sort({ "Availability.Status": 1, Popularity: -1 });：

Availability.Status_1_Popularity_-1

对我来说这很慢。我实际上有另一个索引

{
    "cursor" : "BtreeCursor Availability.Status_1_Popularity_-1",
    "isMultiKey" : false,
    "n" : 913,
    "nscannedObjects" : 470239,
    "nscanned" : 470239,
    "nscannedObjectsAllPlans" : 1387264,
    "nscannedAllPlans" : 1387264,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 10838,
    "nChunkSkips" : 0,
    "millis" : 10117,
    "indexBounds" : {
        "Availability.Status" : [
            [
                -Infinity,
                4
            ]
        ],
        "Popularity" : [
            [
                {
                    "$maxElement" : 1
                },
                {
                    "$minElement" : 1
                }
            ]
        ]
    },
    "server" : "dal05mgo13.sl.dx:27017",
    "filterSet" : false
}

，我认为这是一个更好的选择。但当我强迫mongodb与CategoryPath_1_Availability.Status_1一起使用时，我收到一个错误：

hint

现在我不明白的是，根据{ "$err" : "Runner error: Overflow sort stage buffered data usage of 33581891 bytes exceeds internal limit of 33554432 bytes", "code" : 17144 }中指定的条件，只选择find个结果，即使没有索引，913也不应该耗尽32MB内存来排序913记录。谁能告诉我发生了什么？

我正在使用MongoDB 2.6.10 x86_64

编辑：我的同事刚刚创建了一个新的索引sort，现在正在从其他计划中获胜。我仍然不明白为什么。以下是详细解释信息：

Availability.Status_1_Popularity_-1_CategoryPath_1

Answer 1

那是因为索引中字段的顺序很重要。

CategoryPath_1_Availability.Status_1转换为以下索引顺序：按CategoryPath索引，然后按Availability.Status索引。

但是你希望索引以Availability.Status开头，并且mongo检查是否有任何以Availability.Status（升序）开头的索引，并且没有（在你的朋友创建新索引之前））。订单事宜：）

作为一般规则：假设您在集合中包含以下字段： a，b和c 。让我们在a和b （升序，b升序）上设置索引。 只有当排序以（升序），或（升序）和b 开头时，您才能在排序中使用此索引（上升）。希望你理解：）

查询不会使用合适的索引

1 个答案: