fs.files查询慢主因是缺失针对性索引；应按查询模式建{filename:1}、{projectId:1,uploadDate:-1}等索引，避免全表扫描，并统一filename大小写与空格处理，建索引后必须用explain验证命中效果。
fs.files 查询慢，八成是缺索引覆盖
GridFS 元数据查询卡顿，基本不是驱动或网络问题，而是 fs.files 集合没建对索引。默认只有 _id 索引，但业务几乎从不用 _id 下载——你查的是 filename、uploadDate 或 metadata.projectId，这些字段没索引，MongoDB 就得全表扫描。10 万文件时，一次 find({ filename: "logo.png" }) 可能扫 8 万文档，耗时直接破 200ms。
建什么索引才算“覆盖”，看你的查询条件
索引覆盖（covered query）意味着 MongoDB 能只靠索引本身返回结果，完全不读文档。对 fs.files 来说，常见覆盖场景有限，但合理建索引能极大减少 totalDocsExamined：
- 纯
filename查询 → 建{ filename: 1 }，确保explain("executionStats")中totalDocsExamined≈nReturned - 查某项目下所有文件：
find({ "metadata.projectId": "p123" })→ 别嵌在metadata里建索引，把projectId提到顶层字段（如projectId: "p123"），再建{ projectId: 1, uploadDate: -1 } - 按名称+时间范围查：
find({ filename: /report-2026/, uploadDate: { $gte: ISODate("...") } })→/report-2026/是正则，不走索引；改用前缀匹配 + 复合索引：{ filename: 1, uploadDate: -1 }，并让应用层保证filename命名规范（如"report-20261020.pdf"） - 绝对不要建
{ filename: 1, _id: 1 }：_id 已唯一，加在复合索引末尾无加速效果，还占空间和写放大
collation 和大小写陷阱必须手动处理
默认 MongoDB 区分大小写和首尾空格，find({ filename: "Logo.PNG" }) 查不到 "logo.png"，哪怕你建了索引也没用：
- 入库前统一
trim().toLowerCase()，查询时也做同样归一化 - 或者建带 collation 的索引：
db.fs.files.createIndex({ filename: 1 }, { collation: { locale: "en", strength: 2 } })（strength: 2忽略大小写） - 注意：collation 索引不能和非 collation 查询混用；同一个字段若已有普通索引，得先删掉再重建 collation 版
验证索引是否真生效，别只看 getIndexes()
db.fs.files.getIndexes() 显示索引存在 ≠ 它被命中。必须用 explain 实测：
- 执行
db.fs.files.find({ filename: "test.jpg" }).explain("executionStats") - 重点盯两个值：
executionStats.nReturned（返回几条）和executionStats.totalDocsExamined（扫了几条） - 理想状态是两者相等且都很小；如果
totalDocsExamined是几万而nReturned是 1，说明索引没建对、没命中，或查询用了不支持索引的操作（如$regex开头、$in带太多值） - 建索引时加
{ background: true }避免锁表，但建完务必验证，因为 background 建的索引也可能因数据异常失败
真正难的不是建索引，而是让所有写入路径都遵守同一套命名与字段规范——比如 projectId 永远不塞进 metadata，filename 永远小写无空格。一旦写乱，索引就成摆设。
