MongoDB中四字段索引创建速度慢答案

【问题标题】：Slow creation of four-field index in MongoDBMongoDB中四字段索引创建速度慢
【发布时间】：2014-12-15 20:09:18
【问题描述】：

我在 MongoDB 中有一个 ProductRequest 集合。这是一个有点大的集合，但没有那么多文件。文档数量略多于 300,000，但文档的平均大小接近 1MB，因此数据占用量很大。

为了加快某些查询，我正在为此集合设置索引：

db.ProductRequest.ensureIndex ({processed: 1, parsed: 1, error:1,processDate:1})

前三个字段是布尔值，最后一个是日期时间。

命令运行 24 小时后不会返回

我已经有关于“已处理”和“已解析”字段（一起）的索引以及关于“错误”的单独索引。为什么创建该四字段索引需要很长时间？我的理解是，在这种情况下，个人记录的大小应该无关紧要，我错了吗？

附加信息：

MongoDB 版本 2.6.1 64 位

主机操作系统 Centos 6.5

分片：是的，分片键是_id。分片数量：2，每个分片的副本集数量为3。

【问题讨论】：

您确定您的终端连接没有消失吗？您是否尝试检查索引是否存在于第二个 mongo 客户端中？

标签： mongodb

【解决方案1】：

与仅在processDate 上的索引相比，您不会从这三个字段和processDate 上的索引中看到巨大的好处。在存在其他可索引字段的情况下，布尔字段上的索引不是很有用，因为它们不是很有选择性。如果你给出一个处理日期，那么其他字段的组合通过索引进一步缩小结果的可能性只有8种。

另外，您应该切换顺序。将processDate 放在首位，因为它比布尔字段更具选择性。这应该会大大简化索引并加快索引构建。

最后，在 MongoDB 中创建索引有时不可避免地缓慢且昂贵，因为它涉及创建大型 B 树。当然，绝对值得的回报是更快的查询。索引构建可能需要超过 24 小时。你检查过饱和资源是什么吗？它可能是用于索引构建的 CPU。对于这种情况，您最好的选择是创建索引in the background。后台索引构建

不要像前台索引构建那样在持续时间内阻塞读写操作
需要更长的时间
最初生成较大的索引，随着时间的推移将收敛到等效前台索引的大小

您使用ensureIndex 调用的额外选项将索引构建设置为在后台进行：

db.myCollection.ensureIndex({ "myField" : 1 }, { "background" : 1 })

【讨论】：

【解决方案2】：

我相信这是因为为布尔字段设置了索引。因为只有两个值（true 或 false），如果您有 300.000 行在该字段上放置索引，则必须扫描 150.00 行以查找所有文档，并且在您的情况下，您有 3 个布尔字段，它会使其更慢。

【讨论】：