GridFS 查询必须严格使用 {files_id: 1, n: 1} 复合索引，且查询条件需同时包含 files_id 和 n（$gte 0），排序方向为 n: 1；n 缺失、方向不一致、类型不匹配或索引建在错误 bucket 集合均导致索引失效。
GridFS 查询没走 files_id_1_n_1 索引，先看查询条件字段顺序和方向
GridFS 读取一个文件时，底层会执行类似 db.fs.chunks.find({ files_id: ObjectId("..."), n: { $gte: 0 } }).sort({ n: 1 }) 的查询。它**严格依赖** { "files_id": 1, "n": 1 } 这个复合索引的字段顺序和升序方向。如果查询中 n 是降序、或只查 files_id 不带 n 条件、或用了 $ne/$not 等非范围操作符，索引就可能被跳过。
- 用
explain("executionStats")查看实际执行计划，重点确认"stage": "IXSCAN"是否出现，以及"keyPattern"是否匹配{"files_id":1,"n":1} -
n字段必须参与查询条件：仅靠files_id单字段查询，即使有复合索引，WiredTiger 也大概率退化为COLLSCAN - 避免在
n上使用$gt后再sort({ n: -1 })—— 方向不一致会导致索引无法覆盖排序
驱动层封装可能隐藏真实查询结构，比如 openDownloadStreamByName
很多应用直接调 bucket.openDownloadStreamByName("xxx")，看起来只传了文件名，但背后是两步：先查 fs.files 拿 _id，再用这个 _id 去 fs.chunks 查块。第二步的查询由驱动自动生成，固定为 { files_id: xxx, n: { $gte: 0 } } 并按 n 升序拉取。只要 files_id_1_n_1 存在且有效，这一步就能走索引。
- 如果发现该方法超时或慢，不要怀疑接口本身，先检查
db.fs.chunks.getIndexes()输出里有没有{"files_id":1,"n":1} - Spring Boot 的
GridFsTemplate若配置了自定义bucket名（如"mp4"），则索引必须建在mp4.chunks上，而不是默认的fs.chunks - 手动执行
db.mp4.chunks.find({ files_id: ObjectId("...") }).explain()验证，避免被上层抽象误导
索引存在但 explain 显示未命中，可能是数据类型不一致
常见于应用层把 files_id 当字符串传入查询，而数据库存的是 ObjectId。例如 Node.js 驱动里写成 { files_id: "60a1b2c3d4e5f67890123456" }，MongoDB 不会自动转换类型，导致索引失效，退为全表扫描。
- 用
typeof或ObjectId.isValid()在应用层校验传入值是否为合法 ObjectId 字符串 - 在 mongosh 中用
ObjectId("...")包裹后再查，对比前后explain结果 - 聚合管道中若用
$lookup关联fs.files和fs.chunks，确保localField/foreignField类型完全一致，否则关联字段无法利用索引
重建索引后仍不生效，检查是否在错误的集合上操作
GridFS 默认使用 fs 命名空间，但业务常自定义 bucket 名，如 "reports"、"avatars"。此时索引必须建在对应集合上：db.reports.chunks.createIndex({ files_id: 1, n: 1 })。误建在 fs.chunks 对自定义 bucket 完全无效。
- 运行
db.getCollectionNames().filter(n => n.includes("chunks"))列出所有 chunks 集合，逐个检查索引 - 恢复数据时若用了
mongorestore --noIndexRestore，索引需手工补全，且必须针对每个实际使用的 bucket 分别执行 - 不要依赖“集合存在就代表索引健全”——删除再重建集合会清空所有索引（除
_id_），这是最常被忽略的隐性破坏点
真正卡住 GridFS 读取的，往往不是索引没建，而是建在了看不见的地方、查在了类型错的字段上、或者压根没意识到 bucket 名已变更。每次怀疑索引失效，先用 explain 贴着真实查询语句看，比翻文档更快定位问题。
