compact命令对fs.chunks有效但须连primary节点并严格按序执行：先compact fs.chunks，再compact fs.files；否则无效。若磁盘未释放，需检查并清理孤儿chunk，或考虑dump/restore重建。
compact 命令对 fs.chunks 无效？先确认执行节点和顺序
compact 命令在 GridFS 场景下必须连到 replica set 的 primary 节点执行，secondary 上运行完全无效果。而且不能只 compact fs.files —— 它只存元数据，真正占空间的是 fs.chunks（通常占总存储 90%+）。必须严格按顺序执行：
-
db.runCommand({compact: "fs.chunks"})—— 必须最先执行，且等待完成后再进行下一步 -
db.runCommand({compact: "fs.files"})—— 清理索引碎片，否则后续插入可能触发低效页分裂
如果跳过第一步或顺序颠倒，df -h 看到的磁盘占用几乎不会变化。
compact 后磁盘空间还是没下来？检查孤儿 chunk 和 TTL 索引
执行了 compact 却没释放空间，大概率是 fs.chunks 里存在孤儿分片：即 fs.files 中已删除对应文档，但 fs.chunks 里还留着没主的 chunk 文档。这些文档 compact 不会扫描、也不会清理。
- 用
db.fs.chunks.find({files_id: {$nin: db.fs.files.distinct("_id")}}).count()检查孤儿数量 - 手动清理：先
db.fs.chunks.deleteMany({files_id: {$nin: db.fs.files.distinct("_id")}})，再 compact - 默认 GridFS 不带 TTL 索引，历史碎片不会自动过期；如需自动清理，得给
fs.chunks加files_idTTL 索引（但注意：TTL 不适用于无主 chunk）
compact 阻塞写入且临时磁盘暴涨？评估窗口与空间余量
compact 是重写整个集合的 .wt 文件，期间 fs.chunks 会被独占锁定，所有写入阻塞。更关键的是：它需要额外磁盘空间来暂存新文件，临时占用可能达原 fs.chunks 大小的 1.2 倍。
- 执行前务必用
df -h确认storage.dbPath所在分区有足够空闲（建议 ≥ 当前db.fs.chunks.stats().size× 1.2） - 用
db.currentOp({secs_running: {$gt: 10}})监控是否卡住；若 compact 超过 30 分钟无进展，很可能因磁盘不足或碎片太散而失败 - compact 失败后不要反复重试——WiredTiger 可能已损坏部分页结构，应转向 dump/restore
compact 效果差时别硬扛，该重建就得重建
当 db.fs.chunks.stats().storageSize 远大于 db.fs.chunks.stats().size（比如比值 > 2.5），说明碎片严重，compact 效率极低。此时唯一可靠路径是导出 → 清空 → 重建：
- 停写或切至维护窗口，执行：
mongodump --db yourdb --collection fs.chunks --collection fs.files - 清空集合：
db.fs.chunks.drop()和db.fs.files.drop()（⚠️不是remove({})） - 恢复：
mongorestore—— WiredTiger 会新建紧凑的 .wt 文件，物理空间最小化 - 副本集可先在 secondary 上 dump + restore，再 stepDown 切换 primary，实现近零停机
这个过程需要额外磁盘空间 ≥ 当前数据库总大小，不可省略。也别指望 repairDatabase —— 它在 MongoDB 4.2+ 已弃用，且对 WiredTiger 和 GridFS 完全无效。
