我在MongoDB中有一个ProductRequest集合。这是一个有点大的集合，但没有那么多的文件。文档数量略多于300,000，但文档的平均大小接近1MB，因此数据占用空间很大。
为了加快某些查询，我正在设置此集合的索引：
db.ProductRequest.ensureIndex ({processed: 1, parsed: 1, error:1,processDate:1})
前三个字段是布尔值，最后一个是日期时间。
该命令很快就会运行24小时而不会回来
我已经在'处理'和'解析'字段（一起）上有索引，在'错误'上有一个单独的索引。为什么创建那个四场索引需要永远？我的理解是，在这种情况下，个人记录的大小无关紧要，我错了吗？
其他信息：
MongoDB版本2.6.1 64位
主机OS Centos 6.5
Sharding：是的，分片键是_id。分片数：2，每个分片中的副本集数量为3。
答案 0 :(得分：0)
我 belive 因为为布尔字段添加索引。 因为只有两个值（true或false），如果你有300.000行，那么在该字段上放一个索引就必须扫描150.00行来查找所有文档，在你的情况下你有3个布尔字段，这会使它更慢。 / p>
答案 1 :(得分：0)
您不会从这三个字段的索引中看到巨大的好处，processDate与仅processDate上的索引相比。布尔字段上的索引在存在其他可索引字段时非常有用，因为它们不是非常有选择性的。如果您给出一个处理日期，那么其他字段的组合只有8种可能性，以通过索引进一步缩小结果范围。
此外，您应该切换订单。首先放置processDate，因为它比布尔字段更具选择性。这应该会大大简化索引并加快索引构建。
最后，MongoDB中的索引创建有时不可避免地变得缓慢且昂贵，因为它涉及创建大型B树。当然，收益是绝对值得的，它是更快的查询。索引构建可能需要超过24小时。你检查了饱和资源是什么吗？它可能是索引构建的CPU。这种情况的最佳选择是创建索引in the background。背景索引构建
您可以在后台设置索引构建，并为ensureIndex调用提供额外选项：
db.myCollection.ensureIndex({ "myField" : 1 }, { "background" : 1 })