MongoDB执行deleteMany()后StorageSize反而增大的原因咨询

哈哈，这个现象确实挺反直觉的，我刚接触WiredTiger的时候也懵过。结合你给出的统计数据，尤其是索引大小从3.24GB涨到6.29GB这个关键点，咱们来拆解下背后的原因：

1. WiredTiger的MVCC机制在“拖后腿” #

WiredTiger靠**多版本并发控制（MVCC）**实现读写不冲突，删除文档时它根本不会立刻把数据从磁盘上删掉，只是给旧数据打个“已删除”的标记，还得保留一段时间（由wiredTigerEngineConfigString里的history_store参数控制）。你一下子删了400万条，短时间内生成了大量旧版本数据，这些都会暂时占着磁盘空间，直到后台清理线程或者检查点（checkpoint）跑完才会被处理，这就导致StorageSize先涨了一波。

2. 索引更新的“中间开销”才是大头 #

你看，TotalIndexSize直接翻了快一倍！批量删文档的时候，每个相关索引都要跟着更新。WiredTiger更新索引不是直接删条目，而是先标记删除，之后再慢慢合并整理。这个过程中，索引文件会因为临时的版本记录、碎片整理的中间状态膨胀不少——毕竟400万条记录的索引操作，攒起来的额外空间可不小，直接把整体StorageSize给顶上去了。

3. 预分配策略在“提前占位” #

WiredTiger默认会预分配一些磁盘空间，目的是优化后续写入的性能，避免频繁去申请磁盘块。你删完数据后，虽然释放了8.5GB的可重用空间，但WiredTiger可能提前把这部分空间对应的磁盘块给占了（算在StorageSize里），但实际上这些空间是可以被后续写入重用的，也就是你看到的Available for reuse字段。

4. 检查点没跑完的延迟效应 #

WiredTiger的checkpoint操作会把内存里的数据持久化到磁盘。你刚执行完deleteMany()，可能还没触发自动checkpoint（默认是60秒或者日志到2GB时触发），这时候内存里的删除标记还没同步到磁盘，磁盘上旧数据和新的删除记录同时存在，自然看起来StorageSize变大了。等checkpoint跑完，部分空间会被回收，但可重用空间还是会保留下来。

几个可以试试的验证和解决方法 #

• 手动触发checkpoint：db.runCommand({checkpoint: 1})，跑完再看统计数据，说不定StorageSize就降下来了。
• 针对索引膨胀，试试重建索引：db.collection.reIndex()，这会把索引文件重新整理一遍，回收多余的空间。
• 如果确实要立刻回收磁盘空间，生产环境谨慎用compact命令（会锁集合），或者更安全的方式：把数据导出后重新导入新集合。

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