MongoDB 查询速度过慢，即使查询很简单并且与索引对齐答案

【问题标题】：Unreasonably slow MongoDB query, even though the query is simple and aligned to indexesMongoDB 查询速度过慢，即使查询很简单并且与索引对齐
【发布时间】：2012-01-05 05:11:25
【问题描述】：

我正在运行一个 MongoDB 服务器（实际上就是它所运行的全部内容）。该服务器具有 64GB 的 RAM 和 16 个内核，外加 2TB 的硬盘空间可供使用。

文档结构

该数据库有一个集合domains，其中包含大约 2000 万个文档。每个文档中都有相当数量的数据，但出于我们的目的，该文档的结构如下：

{
    _id: "abcxyz.com",
    LastUpdated: <date>,
    ...
}

_id 字段是文档引用的域名。 LastUpdated 上有一个升序索引。 LastUpdated 每天更新数十万条记录。基本上每次新数据可用于文档时，文档都会更新，并且 LastUpdated 字段会更新为当前日期/时间。

查询

我有一种从数据库中提取数据的机制，因此可以在 Lucene 索引中对其进行索引。 LastUpdated 字段是标记对文档所做更改的关键驱动程序。为了搜索已更改的文档并翻阅这些文档，我执行以下操作：

{
    LastUpdated: { $gte: ISODate(<firstdate>), $lt: ISODate(<lastdate>) },
    _id: { $gt: <last_id_from_previous_page> }
}

sort: { $_id:1 }

当没有文档返回时，开始和结束日期向前移动，_id“锚”字段被重置。此设置可以容忍先前页面中的文档已更改其 LastUpdated 值，即分页不会被先前页面中的文档数量错误地抵消，这些文档在技术上不再在这些页面中。

问题

理想情况下，我希望一次选择大约 25000 个文档，但由于某种原因，查询本身（即使只选择非常很慢。

我运行的查询是：

db.domains.find({
    "LastUpdated" : {
        "$gte" : ISODate("2011-11-22T15:01:54.851Z"),
        "$lt" : ISODate("2011-11-22T17:39:48.013Z")
    },
    "_id" : { "$gt" : "1300broadband.com" }
}).sort({ _id:1 }).limit(50).explain()

事实上，解释（在撰写本文时）已经运行了 10 多分钟并且尚未完成，这实在是太慢了。如果它完成了，我会更新这个问题，但问题当然是查询非常慢。

我能做什么？我不知道查询可能存在什么问题。

编辑讲解在 55 分钟后结束。这里是：

{
    "cursor" : "BtreeCursor Lastupdated_-1__id_1",
    "nscanned" : 13112,
    "nscannedObjects" : 13100,
    "n" : 50,
    "scanAndOrder" : true,
    "millis" : 3347845,
    "nYields" : 5454,
    "nChunkSkips" : 0,
    "isMultiKey" : false,
    "indexOnly" : false,
    "indexBounds" : {
            "LastUpdated" : [
                    [
                            ISODate("2011-11-22T17:39:48.013Z"),
                            ISODate("2011-11-22T15:01:54.851Z")
                    ]
            ],
            "_id" : [
                    [
                            "1300broadband.com",
                            {

                            }
                    ]
            ]
    }
}

【问题讨论】：

标签： mongodb

【解决方案1】：

碰到一个非常相似的问题，Mongodb.org 上的Indexing Advice and FAQ 说，引用：

范围查询也必须是索引中的最后一列

因此，如果您有键 a、b 和 c 并运行 db.ensureIndex({a:1, b:1, c:1})，这些是“指南”，以便尽可能多地使用索引：

好：

find(a=1,b>2)
find(a>1 和 a
find(a>1 and a

不好：

找到(a>1, b=2)

仅对一列使用范围查询或排序。好：

find(a=1,b=2).sort(c)
find(a=1,b>2)
find(a=1,b>2 和 b
find(a=1,b>2).sort(b)

不好：

查找(a>1,b>2)
find(a=1,b>2).sort(c)

希望对你有帮助！

【讨论】：

但在文档中说这不适用于 mongodb 1.6.0+；我正在使用 2.0.6 并且仍然遇到同样的问题。
应该，否则他们声称在使用 B-tree 进行查询时只是违反了“物理定律”。
我们使用索引作为 "c,a,b" 并执行 find(a=x,b=y).sort(c) ，这需要大约 1000 毫秒，然后我使用了索引"a,b,c" ，它开始花费 0 毫秒
@kommradHomer 这可能是由于缓存。重新启动 mongo，然后再次发布结果。

【解决方案2】：

好的，我解决了。罪魁祸首是"scanAndOrder": true，这表明该索引没有按预期使用。正确的复合索引首先具有主排序字段，然后是要查询的字段。

{ "_id":1, "LastUpdated":1 }

【讨论】：

当您有另一个带有额外字段的索引时，您的内存使用量发生了多大变化？
@kommradHomer 对不起，我不记得了；这个问题已经超过三年了

【解决方案3】：

您是否尝试将 _id 添加到您的复合索引中。当您将它用作查询的一部分时，它是否仍需要进行全表扫描？

【讨论】：

我在 LastUpdated (asc) 和 _id (desc) 上有一个复合索引。那是正确的索引吗？