compact命令在分片集群中不可用，仅支持单节点或副本集；需通过停服离线compact、mongodump+restore或ttl索引等方案回收空间。
compact 命令在分片集群中根本不能直接使用
分片集群下，compact 命令不被允许执行——它只支持单副本集或主从部署的 standalone 节点。如果你在 mongos 上运行 db.runCommand({compact: "coll"})，会立刻收到错误："command compact requires authentication as a member of the clusterAdmin role"；即使权限满足，mongos 也会拒绝转发该命令，因为分片架构下每个分片（shard）是独立的存储单元，compact 无法跨分片协调，也不符合分片元数据一致性模型。
真正起作用的是分片节点上的 offline compact（需停服）
若你确实需要回收某个分片上某集合的空间（比如大量删除后 dataSize 显著下降但 storageSize 居高不下），唯一可行路径是：登录到该分片的 对应 shard server（即底层的 replica set primary），并确保它处于维护模式（即临时脱离分片集群）。操作前必须：
- 先用
sh.stopBalancer()暂停均衡器，防止 chunk 迁移干扰 - 用
sh.removeShard("shardName")安全下线目标分片（仅当该分片无 chunk 时才成功；否则需先迁移完） - 停止该分片的 mongod 进程，在 离线状态 下以
--repair启动（WiredTiger 引擎下等效于重建数据文件，释放碎片空间） - 或更稳妥地：用
mongodump+mongorestore --drop重建集合（在线可做，但会引发写入阻塞和短暂不可用）
日常防碎片，靠 WiredTiger 的自动机制 + 合理删除策略
WiredTiger 引擎本身具备空间重用能力，但前提是删除不是“随机散列式”的小文档，而是集中、批量、按索引顺序进行。容易被忽略的关键点：
- 避免在高并发场景下对同一集合频繁执行
deleteMany({status: "archived"})类操作——这会导致 page fragmentation 加剧，WiredTiger 回收滞后 - 改用 TTL 索引自动过期（
db.coll.createIndex({createdAt: 1}, {expireAfterSeconds: 3600})），由后台线程平滑清理，压力更可控 - 定期检查
db.coll.stats()中的scaleFactor、avgObjSize和storageSize / dataSize比值；比值 > 2.5 且长期不降，说明碎片已影响效率 - WiredTiger 默认不立即归还磁盘空间给操作系统，而是保留在 cache 中复用；如需强制释放，只能通过
db.adminCommand({setParameter: 1, wiredTigerEngineConfigString: "cache_size=XXG"})间接触发内存压力下的 page 回收（不推荐随意调）
别指望 balancer 或 moveChunk 解决存储碎片
分片均衡器（balancer）只负责 chunk 分布，moveChunk 是迁移数据块，两者均不触发底层存储引擎的 compact 行为。一次 moveChunk 后，源分片上的旧数据文件不会缩小，只是逻辑标记为“已迁移”，空间仍被占用——直到下次 wiredTiger 后台线程完成 page 整理或你手动干预。
最常被跳过的一步：删完大量数据后，忘记执行 db.coll.reIndex()。虽然它不回收磁盘空间，但能重建 B-tree 结构、减少索引层级碎片，间接提升查询效率——这点在分片环境下同样适用，且可在 mongos 上安全执行。
