gridfs性能瓶颈源于索引老化与存储碎片两类问题：fs.chunks的files_id_1_n_1索引因删除不规范产生空洞导致b-tree分裂，wiredtiger不自动回收空闲页；需先reindex优化结构、再compact释放空间，并彻底清理孤儿元数据以防复发。
GridFS 本身不产生磁盘碎片，真正拖慢查询、虚占磁盘的，是 fs.files 和 fs.chunks 上老化或结构失衡的索引，以及 WiredTiger 底层未回收的空闲页。处理必须分清“索引老化”和“存储碎片”两类问题，不能混用 reIndex 和 compact。
为什么 fs.chunks 的 files_id_1_n_1 索引容易变慢
这个默认索引对写入模式极其敏感：上传文件时 n 递增，物理连续；但删除文件若没走 GridFSBucket.delete()，就会留下 files_id 相同但 n 不连续的空洞。WiredTiger 不会自动合并页，后续插入新 chunk 时复用空洞，导致 B-tree 频繁分裂、页内碎片堆积。
确认是否真碎片化，别只看文档数：
- 查底层空间浪费：
db.fs.chunks.stats().wiredTiger["block-manager"]["file size in bytes"]和db.fs.chunks.stats().size对比，前者比后者大 20% 以上，基本可判定 - 查索引效率：
db.fs.chunks.find({ files_id: ObjectId("...") }).explain("executionStats")，如果totalDocsExamined远大于nReturned，说明扫描跳过了大量无效页
reIndex 和 compact 必须分开用，且顺序不能错
reIndex 只优化 B-tree 结构，不释放物理空间；compact 重写数据文件并回收空闲页，但要求停写。两者目的不同，常需配合：
-
db.fs.chunks.reIndex()和db.fs.files.reIndex()是集合级排他锁，主节点上执行会阻塞所有写入（包括新上传、删除），务必在业务低峰或从节点上操作 -
db.runCommand({ compact: "fs.chunks" })仅支持 WiredTiger 引擎，且必须在副本集 Primary 或分片集群的 shard 节点上运行；执行期间该集合完全不可读写 -
compact对fs.files效果有限（文档少而固定），一般不需要
批量清理“孤儿元数据”才能治本，否则碎片反复再生
fs.files 持续膨胀，99% 是因为只删了 fs.chunks 或业务表引用，却漏掉调用 GridFSBucket.delete() 清理元数据，导致大量无对应 chunk 的文档堆积。
安全清理步骤：
- 先建加速索引：
db.fs.chunks.createIndex({ files_id: 1 }) - 用聚合查孤儿：
db.fs.files.aggregate([ { $lookup: { from: "fs.chunks", localField: "_id", foreignField: "files_id", as: "chunks" } }, { $match: { "chunks.0": { $exists: false } } }, { $project: { _id: 1 } } ]) - 拿到
_id数组后，用db.fs.files.deleteMany({ _id: { $in: [...] } })批量删（别用已弃用的remove） - 每次操作前必须
mongodump备份fs.files集合
最易被忽略的一点：compact 再彻底，也修不好逻辑错误——如果 fs.files 里还存着已删 chunk 的元数据，“孤儿文档”仍在，下次删文件又会重复触发碎片。真正的可持续解法，是把删除收口到统一入口，确保每次删文件都原子性地清理 fs.chunks 和 fs.files 两处数据。
