gridfs删除文件后磁盘空间不释放，是因为wiredtiger仅标记空间“可复用”而不返还os；必须在primary节点依次执行db.runcommand({compact:"fs.chunks"})和db.runcommand({compact:"fs.files"})才能物理回收。
GridFS 文件删了，磁盘空间不降？不是删得不够狠，是 WiredTiger 没把空间还给操作系统——必须用 compact 手动触发物理回收。
为什么 db.fs.files.remove({}) 后磁盘空间毫无变化
GridFS 由 fs.files（元数据）和 fs.chunks（二进制分片）两个集合组成。执行 remove 或 deleteOne 只是逻辑删除文档，WiredTiger 引擎仅将对应磁盘页标记为“可复用”，不会归还 OS。df -h 看不到变化，mongostat 的 mapped 值也几乎不动。
常见错误现象：
- 只删了
fs.files，却漏掉fs.chunks—— 留下大量孤儿 chunk，compact完全扫不到它们 - 在 secondary 节点上执行
compact—— 命令静默失败，无报错但无效果 - 误以为
db.fs.chunks.remove({})就等于清空，结果索引和存储结构仍占空间
必须按顺序执行 compact：先 fs.chunks，再 fs.files
fs.chunks 是空间大户，碎片最重；fs.files 虽小，但不 compact 会导致索引碎片残留，影响后续操作效率。两者都必须在 replica set 的 primary 节点 上执行。
实操步骤：
- 确认当前节点角色：
rs.isMaster().ismaster返回true才能继续 - 执行：
db.runCommand({compact: "fs.chunks"})—— 这步耗时最长，可能阻塞写入（MongoDB - 再执行：
db.runCommand({compact: "fs.files"})—— 快，但跳过它会留下隐性隐患 - 监控进度：
db.currentOp({secs_running: {$gt: 10}})查看是否卡住
compact 失效的典型场景和绕过方案
compact 不是万能的。当 wiredTiger.block-manager.file bytes available for reuse 仍远高于预期，说明碎片太散或文件已严重膨胀，compact 效率极低。
此时应切换策略：
- 停写或切到维护窗口，用
mongodump --db yourdb --collection fs.chunks --collection fs.files导出数据 - 执行
db.fs.chunks.drop()和db.fs.files.drop()—— 注意是drop()，不是remove({}) - 用
mongorestore导回，相当于重建集合，彻底清除碎片 - 全程需预留 ≥ 当前数据库总大小的额外磁盘空间，否则会失败
托管服务如 Atlas 可能禁止或延迟 compact 生效，务必查平台文档或联系支持确认权限。
容易被忽略的关键细节
真正卡住人的从来不是命令怎么写，而是环境判断和前置动作：没确认 primary 角色就开跑，compact 白执行；没导出就直接 drop，数据不可逆；看到 available for reuse 数值下降就以为完事，其实 fs.files 索引碎片还在拖慢查询。碎片回收不是一次 click 就结束的操作，它需要精确的角色控制、空间预估和失败兜底预案。
