gridfs 查询 fs.files 变慢八成因未给 uploaddate 建索引；需用 explain("executionstats") 验证是否 collscan，推荐建 {filename: 1, uploaddate: -1} 复合索引，并确保查询条件中 uploaddate 为 date 类型。
GridFS 查询 fs.files 变慢，八成是因为没给 uploadDate 建索引——尤其当你按上传时间范围查文件（比如“最近7天的PDF”）时，MongoDB 会直接扫完整个 fs.files 集合，哪怕只有几万条记录，也可能拖垮整个副本集。
查 uploadDate 查询有没有走索引
别猜，用 explain("executionStats") 看真实执行路径：
- 执行类似
db.fs.files.find({ uploadDate: { $gte: ISODate("2026-05-05") } }).explain("executionStats") - 重点看
executionStats.nReturned和executionStats.totalDocsExamined：如果后者远大于前者（比如返回12条却扫了8万文档），说明没走索引 - 再看
executionStages.stage：要是显示COLLSCAN，那就坐实了——正在全表扫
uploadDate 单字段索引够不够用
够用，但不推荐只建单字段索引。原因很实际：
- 业务查询往往带组合条件，比如
{ filename: "log.zip", uploadDate: { $gte: ... } }，单uploadDate索引对这种查询帮助有限 -
uploadDate字段本身选择性高（时间戳几乎不重复），但 MongoDB 在复合查询中优先匹配最左前缀，所以{ uploadDate: 1, filename: 1 }这种顺序，对纯uploadDate查询也生效，而反过来不行 - 真正高频的下载接口，常是“按名+按时间”双条件，直接建复合索引一劳永逸：
db.fs.files.createIndex({ filename: 1, uploadDate: -1 })
建完索引还慢？检查这几个隐性坑
索引建了不代表立刻生效，尤其在生产环境：
- 建索引过程本身不阻塞读写，但若集合数据量大（>100万文档），后台建索引可能卡在中间状态，
db.fs.files.getIndexes()显示索引状态是background: true但ready: false，这时查询仍走全表 - Spring Boot 或其他 ORM 启动时自动创建集合，但**不会自动补索引**；如果之前手动删过
fs.files集合，重建后索引就没了，得人工补 - 查询里用了
$regex开头匹配（如{ filename: { $regex: "^report" } }），哪怕有filename索引，MongoDB 也无法使用——这种场景得考虑把前缀提取成独立字段（如prefix: "report"）再建索引
最容易被忽略的一点：uploadDate 是 Date 类型，但应用层传入的可能是字符串或毫秒数。驱动不会自动类型转换，查询条件类型不匹配时，索引直接失效。务必确认你 find 里传的是 new Date(...) 或 ISO 字符串，而不是 "1698765432000" 这种数字。
