repairdatabase 对 gridfs 无效且已弃用，compact 命令仅整理内部碎片但不释放磁盘空间；真正回收需导出→清空→重建或 compactserver + fstrim。
repairDatabase 不能压缩 GridFS 数据文件
直接运行 repairDatabase 对 GridFS 所在数据库无效，它在 MongoDB 4.2+ 版本中已被弃用，且从不支持 WiredTiger 引擎下的空间回收。GridFS 的文件实际存储在 fs.files 和 fs.chunks 两个集合中，删除操作只是移除对应文档，底层数据块仍保留在 WiredTiger 文件中，磁盘空间不会自动释放。
为什么 compact 命令对 GridFS 集合效果有限
执行 db.runCommand({compact: "fs.chunks"}) 确实能整理碎片、合并空闲页，但有三个硬限制：
- 必须停写：整个集合被独占锁定，期间所有读写阻塞
- 不改变文件系统大小：WiredTiger 只重排内部页，
mongod进程不会把“释放出的空间”还给操作系统（除非配合storage.wiredTiger.engineConfig.fileManager.closeIdleTimeSecs配置并等待文件句柄关闭） - chunk 文档本身小（默认 256KB），大量删除后残留的是细碎空洞，compact 效率远低于普通业务集合
真正能回收磁盘空间的组合操作
要让已删除的 GridFS 文件腾出物理磁盘空间，必须走“导出 → 清空 → 重建”路径：
- 先用
mongodump --gzip --db your_db --collection fs.chunks --collection fs.files -o /tmp/gridfs-backup导出剩余有效文件元数据和 chunk 数据 - 停服后手动删除原数据目录下所有
*.wt文件（⚠️仅限维护窗口且确认无其他进程访问） - 重启
mongod，再用mongorestore --gzip /tmp/gridfs-backup重建 —— 此时 WiredTiger 以全新文件写入，无碎片，磁盘占用最小 - 若无法停服，可用
db.adminCommand({compactServer: true})后接文件系统级fstrim（仅限启用了 TRIM 的 SSD + XFS/ext4 挂载选项）
容易被忽略的关键点
GridFS 删除后空间不释放，不是 bug，是 WiredTiger 的设计使然：它优先保障写入吞吐与崩溃恢复能力，而非即时归还磁盘。日常运维中，更应关注 db.fs.chunks.stats().size 与 db.fs.chunks.stats().storageSize 的比值 —— 若后者远大于前者，说明碎片严重，该安排重建了；别依赖任何“一键压缩”命令。
