gridfs 文件删除必须使用 bucket.delete(fileid) 原子操作，否则易产生 fs.files 孤儿文档；手动删 chunks 或业务表id会导致元数据残留、索引膨胀和磁盘空间无法回收，compact 可整理空间但有阻塞风险。

fs.files 和 fs.chunks 集合里的文档没真正删干净，磁盘空间就不会回收——MongoDB 不会自动释放已删除文档占用的物理空间，更不会因你删了业务表引用就顺手清掉 GridFS 元数据或分块。

百度虚拟主播

百度虚拟主播是一款由百度智能云提供的虚拟主播生成、驱动和直播解决方案。

下载

---

fs.files 堆积大量“孤儿”文档

• 常见错误：调用 deleteOne() 或 remove() 只删了业务表里的文件 ID 字段，或手动执行 db.fs.chunks.deleteMany({ files_id: ... })，却漏掉 db.fs.files.deleteOne({ _id: ... })
• fs.files 文档本身很小（几十字节），但它的索引（尤其是默认 { filename: 1, uploadDate: 1 }）会随数量增长显著拖慢写入、抬高内存缓存压力
• 验证方式：运行 db.fs.files.countDocuments({}) 和 db.fs.chunks.countDocuments({})，若前者远大于后者（比如 2 倍以上），基本就是孤儿元数据在堆积

---

dropCollection() 或 deleteMany() 后空间不释放

• MongoDB WiredTiger 引擎不会立即归还磁盘空间给操作系统，只会把空间标记为“可重用”
• 即使你删光了 fs.chunks 所有文档，db.fs.chunks.stats().size 可能仍显示旧值，而 db.fs.chunks.stats().storageSize 才反映实际磁盘占用
• compact 命令能触发空间整理，但它会阻塞集合读写，且要求副本集主节点执行；私有化部署中常因权限或运维策略被禁用

---

大量小文件 + 默认 chunkSizeBytes: 255 * 1024 加剧碎片

• 每个文件至少生成一个 fs.chunks 文档，哪怕只有 1KB；10 万张头像图 ≈ 10 万个 chunk 文档
• 默认分块大小导致 fs.chunks 文档数爆炸，WiredTiger 的页分裂和碎片率上升，缓存效率下降，间接推高整体磁盘占用
• 改大 chunkSizeBytes（如设为 1024 * 1024）能减少文档总数，但要注意：MongoDB wire protocol 单包上限约 16MB，驱动内部仍有缓冲开销，盲目设到 4MB 未必带来线性收益

---

真正该盯住的不是“删没删”，而是“删得干不干净”

• 删文件必须走 bucket.delete(fileId)，这是唯一保证 fs.files 和 fs.chunks 同时清理的原子操作
• 如果用了软删除，别只加字段，得在所有读取路径（比如 openDownloadStreamByName()）里显式过滤 deletedAt: { $exists: false }
• 定期清理不能替代流程管控——上次你手动跑的聚合删孤儿文档，下次上线新功能又绕过 bucket API 直接删 chunks，问题照旧