2

我无法理解这个问题 - 我有一个分片集群，其中一个分片（分片 2）似乎使用了错误的索引。我通过分片键查询，即 site id 和 first request time { site.id: 1, frt: 1 }。我还有一个关于站点 ID 和上次请求时间的索引。

在这个查询中，我还试图通过我在文档中设置的几个布尔值来限制返回的文档。

阅读有关 Mongo 查询优化器如何工作的文档，这对我来说似乎特别奇怪，因为我查看了返回的解释。此处的文档：查询优化器

我还包括了来自 Shard 1 的解释，其中查询按预期返回。最后，如果我使用的站点 ID 没有存储在 Shard 2 上的块，它会使用正确的索引，尽管它没有什么可扫描或返回的。为了完整起见，在末尾添加了对此的解释。

任何想法为什么会发生这种情况和/或如果这是一个错误？

基本查询（坏索引）：

shard2:PRIMARY> db.visit.find({ "site.id": 128, "frt": { $gte: new Date(2012, 8, 24 ) }, "ue": false, "bot": false }).explain()
{
    "cursor" : "BtreeCursor site.id_1_lrt_-1",
    "isMultiKey" : false,
    "n" : 198,
    "nscannedObjects" : 61204,
    "nscanned" : 61204,
    "nscannedObjectsAllPlans" : 61537,
    "nscannedAllPlans" : 61537,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 122,
    "nChunkSkips" : 0,
    "millis" : 727,
    "indexBounds" : {
        "site.id" : [
            [
                128,
                128
            ]
        ],
        "lrt" : [
            [
                {
                    "$maxElement" : 1
                },
                {
                    "$minElement" : 1
                }
            ]
        ]
    },
    "server" : "ip-10-4-211-107:2200"
}

提供提示：

shard2:PRIMARY> db.visit.find({ "site.id": 128, "frt": { $gte: new Date(2012, 8, 24 ) }, "ue": false, "bot": false }).hint("site.id_1_frt_1").explain()
{
    "cursor" : "BtreeCursor site.id_1_frt_1",
    "isMultiKey" : false,
    "n" : 198,
    "nscannedObjects" : 486,
    "nscanned" : 486,
    "nscannedObjectsAllPlans" : 486,
    "nscannedAllPlans" : 486,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 5,
    "indexBounds" : {
        "site.id" : [
            [
                128,
                128
            ]
        ],
        "frt" : [
            [
                ISODate("2012-09-24T07:00:00Z"),
                ISODate("292278995-01--2147483647T07:12:56.808Z")
            ]
        ]
    },
    "server" : "ip-10-4-211-107:2200"
}

相同的查询没有额外的布尔约束（使用正确的索引）：

shard2:PRIMARY> db.visit.find({ "site.id": 128, "frt": { $gte: new Date(2012, 8, 24 ) } }).explain()
{
    "cursor" : "BtreeCursor site.id_1_frt_1",
    "isMultiKey" : false,
    "n" : 486,
    "nscannedObjects" : 486,
    "nscanned" : 486,
    "nscannedObjectsAllPlans" : 486,
    "nscannedAllPlans" : 486,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 1,
    "indexBounds" : {
        "site.id" : [
            [
                128,
                128
            ]
        ],
        "frt" : [
            [
                ISODate("2012-09-24T07:00:00Z"),
                ISODate("292278995-01--2147483647T07:12:56.808Z")
            ]
        ]
    },
    "server" : "ip-10-4-211-107:2200"
}

在 Shard 1 上，原始查询使用预期索引：

shard1:PRIMARY> db.visit.find({ "site.id": 253, "frt": { $gte: new Date(2012, 8, 24 ) }, "ue": false, "bot": false }).explain()
{
    "cursor" : "BtreeCursor site.id_1_frt_1",
    "isMultiKey" : false,
    "n" : 15615,
    "nscannedObjects" : 15950,
    "nscanned" : 15950,
    "nscannedObjectsAllPlans" : 16152,
    "nscannedAllPlans" : 16152,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 125,
    "nChunkSkips" : 0,
    "millis" : 237,
    "indexBounds" : {
        "site.id" : [
            [
                253,
                253
            ]
        ],
        "frt" : [
            [
                ISODate("2012-09-24T07:00:00Z"),
                ISODate("292278995-01--2147483647T07:12:56.808Z")
            ]
        ]
    },
    "server" : "ip-10-6-50-253:2100"
}

在 Shard 2 上查询此处没有块的站点（使用正确的索引）：

shard2:PRIMARY> db.visit.find({ "site.id": 253, "frt": { $gte: new Date(2012, 8, 24 ), "ue": false, "bot": false } }).explain()
{
    "cursor" : "BtreeCursor site.id_1_frt_1",
    "isMultiKey" : false,
    "n" : 0,
    "nscannedObjects" : 0,
    "nscanned" : 0,
    "nscannedObjectsAllPlans" : 0,
    "nscannedAllPlans" : 0,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 0,
    "indexBounds" : {
        "site.id" : [
            [
                253,
                253
            ]
        ],
        "frt" : [
            [
                ISODate("2012-09-24T07:00:00Z"),
                ISODate("292278995-01--2147483647T07:12:56.808Z")
            ]
        ]
    },
    "server" : "ip-10-4-211-107:2200"
}
4

1 回答 1

3

您链接的文档中的几件事可能会解释这种行为，首先：

在 1,000 次操作之后以及在对集合进行某些操作（例如添加索引）之后重复查询测试。

因此，如果您没有足够的查询量对其进行评估，它将坚持首选。

第二：

为了解决这个问题，在测试新计划时，MongoDB 会并行执行多个查询计划。一旦完成，它就会终止其他执行，并且系统已经知道哪个计划是好的。

如果另一个索引已经在内存中，比如说因为它正在被另一个查询使用，或者正在发生的其他事情会减慢首选索引上的查询执行速度（或者它非常接近并且偶尔会在速度方面进行交换） ，然后您将再次返回“坏”索引。

优化器已在 2.2 中进行了调整和改进，因此如果您仍然遇到问题（并且在 2.0 或更低版本上），可能值得一看。或者，正如您在测试中所做的那样，如果您知道要使用的最佳索引，只需消除所有疑问并使用提示来指定它。

于 2012-09-24T23:29:09.933 回答