确认fs.chunks是否丢失files_id索引：升级到MongoDB 4.4后，GridFSBucket不再自动补建索引，需手动执行db.fs.chunks.getIndexes()检查{ "files_id": 1 }及{ "files_id": 1, "n": 1 }复合索引是否存在，缺失则立即创建，否则下载性能将断崖下跌。
确认fs.chunks是否丢失files_id索引
升级到 MongoDB 4.4 后，fs.chunks 集合的 files_id 索引可能被意外丢弃——这不是 bug，而是驱动行为变更的副作用：4.4+ 版本中，GridFSBucket 初始化不再自动补建缺失索引（旧版驱动会在首次写入时兜底），而很多系统是靠历史写入“触发”建索引的，升级后若没新上传，索引就一直空缺。
实操建议：
- 连上数据库，执行
db.fs.chunks.getIndexes()，检查输出里有没有{ "files_id": 1 } - 如果缺失，立刻运行
db.fs.chunks.createIndex({ "files_id": 1 }) - 别依赖“升级后自动重建”——MongoDB 官方明确说明：索引需显式维护，驱动不负责兜底
检查fs.files元数据查询是否也缺索引
下载流程分两步：先查 fs.files 拿元数据，再按 files_id 查 fs.chunks。如果 fs.files 上没有 filename 或复合索引（如 { filename: 1, uploadDate: -1 }），openDownloadStreamByName() 就会慢，尤其在文件量大的库中。
实操建议：
- 执行
db.fs.files.getIndexes()，确认是否有{ "filename": 1 }或业务常用字段的索引 - 若只有默认
_id索引，加一个：db.fs.files.createIndex({ "filename": 1 }) - 如果用
metadata字段查（比如bucket.find({ "metadata.userId": "xxx" })），必须为该路径建索引：db.fs.files.createIndex({ "metadata.userId": 1 })
避免误删索引导致二次故障
有人升级后发现查询变慢，顺手跑 db.fs.chunks.dropIndexes() 再重试——这是高危操作。MongoDB 4.4 对 GridFS 的 chunk 查询强依赖 files_id 和 n 的联合顺序，光有 files_id 不够，还必须有 { "files_id": 1, "n": 1 } 索引，否则流式读会退化为全表扫描。
实操建议：
- 不要盲目
dropIndexes，先看现有索引结构 - 必须保留或重建这个复合索引：
db.fs.chunks.createIndex({ "files_id": 1, "n": 1 }) - 验证方式：用
db.fs.chunks.explain("executionStats").find({ files_id: ObjectId("..."), n: 0 })，确认executionStats.executionStages.stage是IXSCAN而非COLLSCAN
升级后首次上传不触发索引，怎么办
你可能会想：“我马上上传个测试文件，让驱动自动建索引”。但 MongoDB 4.4+ 的 GridFSBucket 已移除该逻辑——openUploadStream() 只写数据，不检查、不建、不报错索引缺失。
实操建议：
- 升级后必须人工补全索引，不能等业务触发
- 把索引创建语句纳入部署 checklist，和 migration 脚本一起执行
- 上线前用
db.runCommand({ validate: "fs.chunks" })快速验证集合健康度（注意：该命令会锁表，选低峰期）
files_id 单字段索引和 { files_id: 1, n: 1 } 复合索引这两条，漏掉任何一条都会让 GridFS 下载性能断崖下跌——而且错误现象隐蔽，容易归因为网络或磁盘，实际根子就在索引缺失。 
