GridFS 本身不提供文件级压缩能力，如需压缩大文件，必须在应用层手动处理；而删除文件后磁盘空间不立即释放，则是 WiredTiger 存储引擎的设计特性所致。若想彻底回收空间，通常只能通过导出→清空→重建的方式完成。
GridFS 自身并不支持文件级自动压缩。很多人提到“压缩 MongoDB GridFS 大文件”，实际通常包含两个完全不同的问题：一是上传前如何缩小文件体积，也就是应用层压缩；二是删除文件后如何回收已经占用的磁盘空间，也就是存储层空间整理。这两件事本质不同，但在实际使用中经常被混淆。
上传前用 gzip / zlib 压缩原始文件再存入 GridFS
GridFS 不会自动压缩文件内容，它只是把输入流按块切分后原样写入 fs.chunks 集合。想减少 GridFS 存储占用，正确做法是在写入 MongoDB 之前由应用程序先完成压缩。
- 对文本类文件，例如日志、JSON、XML，压缩效果通常很明显；但对 JPEG、MP4、ZIP 这类本身已经压缩过的格式，基本没有效果，甚至可能让文件体积略有增加
- Python 示例：
fs.put(gzip.compress(file_bytes), filename="report.json.gz", metadata={"original_name": "report.json"}) - Ja va 中可使用
ja va.util.zip.GZIPOutputStream包装InputStream，然后再传给GridFSInputFile - 建议务必在
metadata或文件名里保留原始格式信息，否则文件读取出来后可能无法正确解压或还原
删除大量文件后，compact 命令无法释放磁盘空间
很多人在执行 db.runCommand({compact: "fs.chunks"}) 之后，会发现用 du -sh 查看磁盘占用几乎没有变化。这并不代表命令无效，而是因为 WiredTiger 的工作机制决定了它不会轻易把空间直接归还给文件系统。
compact的作用主要是整理内部数据页、合并空闲 slot，但不会直接触发文件系统层面的空间释放fs.chunks中的文档通常较小（默认 256KB/chunk），大量删除后形成的往往是零散碎片，这也导致compact在该集合上的回收效果通常弱于普通业务集合- 执行该命令时需要对集合加独占锁，在此期间相关读写都会被阻塞，因此生产环境或线上业务场景要谨慎使用
真正回收磁盘空间必须走导出→清空→重建流程
在 WiredTiger 引擎下，如果目标是实际缩小 .wt 文件的物理大小，最可靠的方法仍然是重建数据文件，而不是单纯依赖压缩或整理命令。
- 先导出仍然有效的数据：
mongodump --gzip --db your_db --collection fs.files --collection fs.chunks -o /backup/ - 停止 mongod，手动删除数据目录中的所有
fs.*.wt文件（⚠️仅适用于维护窗口，并确认没有其他进程正在访问） - 重新启动 mongod，再执行
mongorestore --gzip /backup/完成导入——这样会生成全新的、无明显碎片的.wt文件 - 如果业务无法停机，也可以尝试
db.adminCommand({compactServer: true})配合文件系统级fstrim（仅适用于 SSD + XFS/ext4，并且启用了discard挂载选项）
还有一个在 MongoDB GridFS 运维中非常容易被忽略的细节：文件删除后空间没有马上释放，通常并不是操作失误，也不一定是数据库异常，而是 WiredTiger 为了兼顾写入性能与崩溃恢复能力所做的设计权衡。日常排查时，建议重点关注 db.fs.chunks.stats().storageSize / db.fs.chunks.stats().size 这个比值；如果超过 2.0，通常就说明碎片问题已经比较严重，数据库重建和空间回收方案就应尽快纳入处理计划。
