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

As per the MongoDB documentation, there is generally no need to routinely rebuild indexes.

注意：MongoDB 3.0+对存储的任何建议都会变得更有趣，它引入了可插拔存储引擎API 。我在下面的评论是专门参考MongoDB 3.0及更早版本中的默认MMAP存储引擎。 WiredTiger和其他存储引擎具有不同的数据存储实现方式。索引。

NOTE: Any advice on storage becomes more interesting with MongoDB 3.0+, which introduced a pluggable storage engine API. My comments below are specifically in reference to the default MMAP storage engine in MongoDB 3.0 and earlier. WiredTiger and other storage engines have different storage implementations for data & indexes.

在以下情况下使用MMAP存储引擎重建索引可能会有一些好处：

There may be some benefit in rebuilding an index with the MMAP storage engine if:

• 与数据相比，索引占用的空间量大于预期。注意：您需要监控历史数据和索引大小，以便进行比较。

• An index is consuming a larger than expected amount of space compared to the data. Note: you need to monitor historical data & index size to have a baseline for comparison.

您希望从较旧的索引格式迁移到较新的索引格式。如果建议使用reindex，则会在升级说明中提及。例如，MongoDB 2.0引入了重要的索引性能改进所以发行说明包括升级后建议的v2.0格式重新索引。同样，MongoDB 2.6引入了 2dsphere （v2.0）索引具有不同的默认行为（默认为稀疏）。索引版本升级后不会重建现有索引;是否/何时升级的选择由数据库管理员决定。

You want to migrate from an older index format to a newer one. If a reindex is advisible this will be mentioned in the upgrade notes. For example, MongoDB 2.0 introduced significant index performance improvements so the release notes include a suggested reindex to the v2.0 format after upgrading. Similarly, MongoDB 2.6 introduced 2dsphere (v2.0) indexes which have a different default behaviour (sparse by default). Existing indexes are not rebuilt after index version upgrades; the choice of if/when to upgrade is left to the database administrator.

您已更改 _id 将单调增加的密钥（例如，ObjectID）或从单调增加的密钥（例如，ObjectID）的集合格式化为随机值。这有点深奥，但如果你要插入总是在增加的 _id ，那么有一个索引优化可以将b-tree桶分成90/10（而不是50/50） （参考： SERVER-983 ）。如果 _id 的性质发生显着变化，则可以使用重新索引构建更高效的b树。

You have changed the _id format for a collection to or from a monotonically increasing key (eg. ObjectID) to a random value. This is a bit esoteric, but there's an index optimisation that splits b-tree buckets 90/10 (instead of 50/50) if you are inserting _ids that are always increasing (ref: SERVER-983). If the nature of your _ids changes significantly, it may be possible to build a more efficient b-tree with a re-index.

有关一般B树行为的更多信息，请参阅：***：B树

For more information on general B-tree behaviour, see: Wikipedia: B-tree

如果你真的很想要深入研究索引内部，你可以尝试一些实验性的命令/工具。我希望这些仅限于MongoDB 2.4&仅限2.6：

If you're really curious to dig into the index internals a bit more, there are some experimental commands/tools you can try. I expect these are limited to MongoDB 2.4 & 2.6 only:

• indexStats 命令


• storage-viz 工具

• indexStats command
• storage-viz tool