mongodb - 为什么以及何时需要在 MongoDB 中重建索引？

Question

使用 MongoDB 有一段时间了，今天在和同事讨论时遇到了疑问。

问题是当你在 MongoDB 中创建索引时，会处理集合并构建索引。

索引会在文档的插入和删除过程中更新，因此我认为不需要运行重建索引操作(删除索引然后重建它)。

根据 MongoDB 文档:

Normally, MongoDB compacts indexes during routine updates. For most users, the reIndex command is unnecessary. However, it may be worth running if the collection size has changed significantly or if the indexes are consuming a disproportionate amount of disk space.

是否有人需要运行值得的重建索引操作？

Answer 1

根据 MongoDB 文档，通常不需要定期重建索引。

注意:任何关于存储的建议在 MongoDB 3.0+ 中都会变得更有趣，它引入了 pluggable storage engine API .我在下面的评论专门针对 MongoDB 3.0 及更早版本中的默认 MMAP 存储引擎。 WiredTiger 和其他存储引擎对数据和索引有不同的存储实现。

如果满足以下条件，使用 MMAP 存储引擎重建索引可能会有一些好处:

• 与数据相比，索引占用的空间量超出预期。注意:您需要监控历史数据和索引大小以获得比较基准。

• 您想从旧的索引格式迁移到新的索引格式。如果建议重新索引，这将在升级说明中提及。例如，MongoDB 2.0 引入了重要的 index performance improvements所以发行说明包括升级后对 v2.0 格式的建议重新索引。同样，MongoDB 2.6 引入了 2dsphere (v2.0) indexes它们具有不同的默认行为(默认稀疏)。索引版本升级后不重建现有索引；是否/何时升级由数据库管理员选择。

• 您已将集合的 _id 格式更改为单调递增的键(例如 ObjectID)或随机值。这有点深奥，但是如果您插入总是增加的 _id，则有一个索引优化可以将 b-tree 存储桶拆分为 90/10(而不是 50/50)(引用:SERVER-983 )。如果您的 _id 的性质发生显着变化，则可以使用重新索引构建更高效的 b-tree。

有关一般 B 树行为的更多信息，请参阅:Wikipedia: B-tree

可视化索引使用情况

如果您真的很想深入了解索引内部结构，可以尝试一些实验性命令/工具。我希望这些仅限于 MongoDB 2.4 和 2.6:

• indexStats command
• storage-viz tool