GridFS必须存在的索引有两个：fs.files的_id主键索引（自动创建、不可重建，丢失需恢复备份）和fs.chunks的{"files_id": 1, "n": 1}复合索引（缺失将导致读取乱序、超时或全表扫描）；此外，按filename或metadata查询需手动建立对应索引。
GridFS 的索引一旦损坏或缺失，find、findOne、文件流式读取等操作会变慢甚至失败，但 MongoDB 不会报错提示“索引缺失”，只会 silently 退化为全集合扫描。修复必须手动干预，不能依赖驱动自动重建。
哪些 GridFS 索引必须存在且不可缺失
GridFS 依赖两个核心集合：fs.files 和 fs.chunks，各自有不可省略的索引：
-
fs.files必须有_id主键索引（MongoDB 自动创建，无法手动重建；若丢失，只能从备份恢复） -
fs.chunks必须有复合索引{"files_id": 1, "n": 1}—— 这是 chunk 定位和顺序拼接的关键，丢失后文件读取会乱序或超时 -
fs.files建议有{"filename": 1, "uploadDate": -1}，否则按文件名+时间查询效率极低
执行 createIndex 修复 chunks 索引的实操要点
直接运行命令即可，但要注意以下细节：
- 必须在
fs.chunks集合上执行：db.fs.chunks.createIndex({"files_id": 1, "n": 1}) - 不要加
{background: true}：4.4 中 background 创建对chunks这类高写入集合风险较大，容易因长时间持有锁导致应用卡顿；建议在低峰期前台执行 - 确认索引名是否已存在：先查
db.fs.chunks.getIndexes()，避免重复建索引拖慢写入 - 如果集合已有大量数据（比如千万级 chunk 文档），建索引可能耗时数分钟到小时，期间
fs.chunks写入会被阻塞（4.4 不支持可中断/可恢复索引构建）
metadata 字段搜索索引怎么加才有效
如果你常按 metadata.project 或 metadata.tags 查询文件，需单独建索引：
- 单字段：如
db.fs.files.createIndex({"metadata.project": 1}) - 数组字段（如
tags）必须用多键索引，MongoDB 会自动识别，无需额外参数：db.fs.files.createIndex({"metadata.tags": 1}) - 复合查询推荐组合：例如查“某项目下最新上传的前 5 个文件”，建
db.fs.files.createIndex({"metadata.project": 1, "uploadDate": -1})比只建uploadDate更高效 - 避免在
metadata上建通配符索引（如{"metadata.$**": 1}），它会让fs.files写入明显变慢，且对 GridFS 场景收益很低
为什么不能靠驱动自动重建索引
MongoDB 驱动只在“首次写入且集合为空”时自动建默认索引。一旦集合已有数据，哪怕索引被误删，驱动也不会补建。你看到的“一切似乎还能用”，只是因为查询降级成了 collection scan —— 数据量一上来，延迟就飙升，而错误日志里根本不会体现索引问题。
最容易被忽略的是 files_id_1_n_1 索引缺失后的表现：文件能存、能删，但读大文件时偶发 RangeError: Maximum call stack size exceeded 或流式响应中断，根源就是 chunk 顺序无法保障。
