GridFS查询fs.files变慢八成因未建uploadDate或filename索引，导致COLLSCAN全表扫描；用explain("executionStats")确认nReturned远小于totalDocsExamined且stage为COLLSCAN即可判定；应建{filename:1}、{filename:1,uploadDate:-1}或{uploadDate:-1}索引，避免最左前缀失效、类型不匹配、后台索引未就绪、regex开头、大小写/空格不一致及孤儿文档等问题。
GridFS 查询 fs.files 变慢，八成是因为没给 uploadDate 或 filename 建索引——尤其当你按“最近7天PDF”或“用户头像”这类条件查时，MongoDB 会直接 COLLSCAN 整个集合，哪怕只有几万条记录，也可能拖垮副本集。
怎么确认是不是索引缺失导致的全表扫描
别靠猜，用 explain("executionStats") 看真实执行路径：
- 执行类似
db.fs.files.find({ filename: "report.pdf" }).explain("executionStats")或db.fs.files.find({ uploadDate: { $gte: ISODate("2026-10-15") } }).explain("executionStats") - 重点看
executionStats.nReturned和executionStats.totalDocsExamined：如果后者远大于前者（比如返回 1 条却扫了 8 万文档），说明没走索引 - 再看
executionStages.stage：显示COLLSCAN就坐实了——正在全表扫
该建什么索引才真正生效
默认只有 _id 索引，业务查询几乎都用不上。建错顺序或类型，索引等于没建：
- 高频按文件名查 → 建
{ filename: 1 }；若还常按时间排序（如“最新上传的 logo.png”），直接上复合索引{ filename: 1, uploadDate: -1 } - 只按
uploadDate范围查（如“过去24小时”）→ 单字段索引{ uploadDate: -1 }够用，但不如复合索引通用 - 千万别建
{ uploadDate: -1, filename: 1 }然后只查filename：MongoDB 不会跳过最左前缀，这种索引对纯filename查询无效 - 所有索引必须配合类型一致的查询条件：
uploadDate字段是Date类型，但你传的是字符串"2026-10-15"或毫秒数1729440000000？索引直接失效
建完索引还慢？检查这几个隐性坑
索引建了不等于立刻起效，尤其在生产环境：
- 后台建索引可能卡住：
db.fs.files.getIndexes()显示background: true但ready: false，这时查询仍走全表 - Spring Boot 启动自动建集合，但**不会补索引**；如果之前手动删过
fs.files，重建后索引就没了，得人工补 -
$regex开头匹配（如{ filename: { $regex: "^report" } }）无法使用filename索引，考虑把前缀提取成独立字段（如prefix: "report"）再建索引 - 索引建得再好，如果查询里混用了大小写、前后空格（如
" LOGO.PNG "），而建索引时没配collation，照样查不到
最容易被忽略的一点：索引能加速查找，但解决不了元数据膨胀本身。如果 fs.files 里积压了几万条“孤儿文档”（对应 fs.chunks 已删但元数据没清理），再好的索引也得扫一堆无效数据——得先跑聚合查孤儿，再 deleteMany 清理。
