为何MongoDB 4.2（WiredTiger引擎）执行compact命令后集合存储大小增加？

我完全理解你的困惑——执行compact命令本想着回收磁盘空间，结果storageSize反而上升，这确实和直觉不符。咱们来拆解这个现象背后的原因，同时确认你的操作和指标选择有没有问题：

首先，你选的指标是对的，但要理解它的真实含义 #

storageSize是WiredTiger分配给集合的磁盘空间总量，包含已使用的空间和预分配但未使用的空间。这个指标能反映WiredTiger为集合预留的磁盘资源，但不能完全等同于实际被数据占用的磁盘空间。

为什么compact后storageSize会上升？ #

WiredTiger的compact命令不只是简单回收碎片空间，它的核心作用是重新组织数据的页结构、优化存储布局，提升后续读写性能。在这个过程中，可能出现以下情况导致storageSize上升：

• 临时空间分配：重组数据时，WiredTiger会先分配新的存储空间来存放整理后的页，之后才会释放旧的碎片化空间。如果操作刚完成，旧空间还没被系统或WiredTiger回收，就会出现总分配空间暂时上升的情况。
• 预分配机制触发：WiredTiger会为集合预分配部分空间，避免频繁的磁盘IO操作。如果compact后数据布局更规整，WiredTiger可能判断后续有写入需求，主动预分配了更多空间，直接拉高了storageSize。
• 碎片本来就很少：如果你的集合之前删除/更新操作不多，碎片率很低，compact不仅没有多少空间可回收，反而因为重组过程的临时空间占用，导致storageSize上升——这完全符合官方文档提到的“操作效果取决于工作负载”的描述，只是文档没细化这种反向变化的场景。

你的操作有没有问题？ #

你的操作步骤是正确的：先查询storageSize，执行db.runCommand({compact:"bikes"})（返回ok:1说明执行成功），再复查指标。不过有几个细节可以注意：

• compact在WiredTiger下是阻塞式操作，执行期间集合无法接受写入，你确认操作完成即可。
• 如果你想查看实际回收的磁盘空间，建议结合这两个指标：
  • freeStorageSize：集合中未使用的存储空间大小，这个值的变化能直接反映碎片回收情况；
  • totalSize：集合数据+索引的总占用大小，更贴近实际数据的磁盘占用。
    另外，也可以直接查看数据库目录下对应集合的.wt文件大小，这是最直观的磁盘占用数据。

额外建议 #

WiredTiger默认会在后台自动进行碎片整理，除非你有明确的性能优化需求（比如大量随机读需要更规整的页结构），否则不需要手动执行compact。如果你的核心需求是回收磁盘空间，只有当freeStorageSize占storageSize的比例较高时，手动compact才会有明显效果。

内容的提问来源于stack exchange，提问作者fgalan