compact不能真正释放磁盘空间，因wiredtiger仅标记空间可复用而不截断文件；其唯一适用场景是高频小文档增删导致页内碎片、缓存效率下降时的局部优化。
compact 命令不能直接回收已删除文档释放的空间，它只对 WiredTiger 存储引擎下的集合做碎片整理和页合并，且要求副本集主节点或单机实例——在大多数生产场景中，它既不自动触发，也不推荐手动执行。
为什么 compact 在 WiredTiger 上效果有限
WiredTiger 默认启用 block_manager 的内部空间重用机制：删除文档后，空间会先被标记为“可复用”，而非立即归还给操作系统。此时 compact 仅尝试将分散的空页合并、提升局部性，但不会调用 truncate 或 fsync 向 OS 归还内存映射文件（.wt 文件）的实际磁盘空间。
- 执行后
db.collection.stats().size可能不变，storageSize可能微降，但dataSize不变 - 必须在主节点上运行，副本集从节点拒绝该命令
- 执行期间集合会被加读锁（WiredTiger 3.2+ 改为更细粒度锁，但仍阻塞写入）
- 不适用于 mmapv1 引擎（已弃用，且
compact对其作用更弱）
真正释放磁盘空间的替代方案
想让 .wt 文件体积缩小、释放磁盘空间，需触发底层存储引擎的文件截断（truncate），这只有两个可靠路径：
-
重建集合：用
db.collection.renameCollection()备份原集合，再用db.collection.copyTo()（已废弃）或更稳妥的db.collection.aggregate([{$out: "new_name"}])创建新集合，最后删旧表。新集合的.wt文件从零分配，无历史碎片 -
停机导出导入：用
mongodump --db mydb --collection coll导出，删集合，再用mongorestore导入。适合维护窗口可控的集群 - 若使用 MongoDB Atlas，可直接触发「Resync Secondary」或「Rebuild Indexes」操作，后台自动完成类似重建
compact 的正确使用时机与参数
它唯一值得用的场景是：某集合经历了高频小文档增删（如 IoT 时间序列打点），且观察到 db.collection.stats().nindexes 正常但 avgObjSize 显著上升、查询延迟增加——这时可能是页内碎片导致缓存效率下降。
- 命令格式：
db.runCommand({compact: "coll_name"})，不可带选项（如force或padding） - 必须在
admin数据库下执行；不能跨库 compact 其他数据库的集合 - 执行后检查返回字段：
"ok": 1表示启动成功，但需查日志确认是否完成（grep "COMPACT" /var/log/mongodb/mongod.log） - 切勿在业务高峰期执行；监控
globalLock.totalTime和metrics.record.moves避免长锁
实际运维中，与其纠结 compact 能否“回收空间”，不如把精力放在定期评估集合膨胀率（storageSize / dataSize > 3x 就该干预）、设置合理的 TTL 索引自动清理，以及用 collMod 调整 usePowerOf2Sizes（已默认关闭）等更可控的手段上。
