7虽然我不知道为什么在MongoDB中可以这样做的确切技术原因，但我可以根据我对其他系统索引的了解和您引用的文档来做出一些假设。
索引的基本思想是：在完整的文档集合中移动时，跳过所有不需要处理的数据会浪费很多时间和精力。如果你要查找id为“1234”的文档，必须移动100K+每个文档，这样就会很慢。
索引使这个过程变得快速，而不必搜索集合中每个文档的所有内容（物理移动磁盘读头等）。它基本上是一个键值对，给出id和该文档的位置。MongoDB可以快速扫描索引中的所有id，找到它需要的文档的位置，并直接加载它们。
索引占用磁盘空间，因为它们基本上是存储在更小位置的键值对。如果你有一个非常大的集合（集合中的项目数量很多），那么你的索引会增长。
大多数操作系统分配某些块大小的磁盘空间。大多数数据库也按需要分配大块磁盘空间。
MongoDB不会在添加100K个文档时增加100K的文件大小，而是可能增加1MB或10MB等 - 我不知道实际增长大小是多少。在SQL Server中，你可以告诉它增长的速度，MongoDB可能也有类似的功能。
以块为单位增长使得能够更快地将文档增长到空间中，因为数据库不需要不断扩展。如果数据库已经分配了10MB的空间，它只能使用那些空间。它不必为每个文档不断扩展文件。它只需将数据写入文件即可。
这对于存储在磁盘上的任何集合和索引可能都是正确的。
当大型集合添加和删除许多文档时，索引会变得分散。索引键可能不按顺序排列，因为在构建索引时在中间位置有空间而不是在末尾。索引键之间可能有很多空间。
如果索引中有10,000个项目，并且需要插入# 10,001，则可能会插入到索引文件的中间。现在索引需要重新构建自身以将所有内容放回原来的顺序。这涉及移动大量数据，以在文件末尾腾出空间并将项目＃10,001放在末尾。
如果索引一直被摧毁 - 大量的东西被删除和添加 - 那么最好的方法可能是增加索引文件大小，并始终将东西放在末尾。这样创建索引很快，但在旧的东西被删除时会在文件中留下空洞。
如果索引文件中存在已删除内容占用的空间，这在读取索引时是浪费的。索引文件的移动比需要的要多，以获取到索引中的下一个项目。因此，索引会进行自我修复......对于非常大的集合或集合发生非常大的变化，这可能需要耗费很长时间。
重建大型索引文件
正确地压缩索引文件至合理大小，并使其有序，需要执行大量磁盘访问和I/O操作。将不在应该位置的项目移动到临时位置，释放出应在正确位置的空间，然后将它们移回原处。顺便说一下，为了释放空间，您必须将其他项目移动到临时位置。这是递归和笨拙的方法。
因此，如果您的集合中有大量项目，并且该集合定期添加和删除项目，则可能需要从头开始重新构建索引。这样做将抹掉当前的索引文件并从头开始重建-这可能比尝试在现有文件中执行数千次移动要快。它只是从头开始按顺序写入它们。
集合大小的大量更改
考虑到我上面所假设的所有内容，集合大小的大量更改会导致这种混乱。 如果您的集合中有10,000个文档，并且您删除了其中的8,000个...好吧，现在您的索引文件中有8,000个项目曾经占用的空间。 MongoDB需要在物理文件中移动剩余的2,000个项目，以便以紧凑形式重建它。
与其等待清除8,000个空白空间，不如从头开始重建剩下的2,000个项目，这可能更快。
结论？也许？
因此，您引用的文档可能涉及“大数据”需求或高混乱集合和索引。
还要记住，我正在根据自己对索引、磁盘分配、文件碎片等方面的知识做出教育猜测。
我猜“大多数用户”在文档中表示99.9%或更多的mongodb集合不需要担心这个问题。
MongoDB特定情况
根据MongoDB文档：
remove()方法不会删除索引
因此，如果您从集合中删除文档，则会浪费磁盘空间，除非您重建该集合的索引。
- Derick Bailey18很不幸，你对索引的描述缺少B树数据结构的基本概念，并且并不准确地表示了MongoDB中索引的工作原理 :). 键存储在桶中，表示值的范围…插入或删除单个文档并不需要“重建”索引，只需将键添加到数据结构的适当位置即可。维基百科上有更好的描述。至于remove()命令：它不会删除索引定义（但确实会删除索引条目）。 - Stennie