对 filename 和 uploadDate 建复合索引是必要操作，因 GridFS 默认索引仅首次写入时自动创建，缺失时百万级文件查询将退化为全表扫描；必须使用 { filename: 1, uploadDate: 1 } 复合索引并配合正确查询写法才能生效。
为什么对 filename 和 uploadDate 建索引是必要操作
GridFS 默认会在 fs.files 集合上建一个复合索引 { filename: 1, uploadDate: 1 }，但这个索引只在首次写入时由驱动自动创建——如果集合已存在且之前没写过文件，或你手动清空过 fs.files，这个索引很可能根本不存在。百万级小文件下，没索引的 find({ filename: "xxx" }) 就是全表扫描，响应从毫秒级拖到秒级甚至超时。
建索引前先确认当前索引状态
别盲目执行 createIndex，先查清楚有没有、是否有效：
- 运行
db.fs.files.getIndexes()，看输出里是否有{ "key": { "filename": 1, "uploadDate": 1 } } - 注意：如果只有
{ "filename": 1 }单字段索引，它对{ filename: "a", uploadDate: { $gt: ... } }这类查询无效，必须是复合索引 - 如果索引存在但
size字段异常小（比如远小于文档数），说明它可能被损坏或未完全构建，需重建
建索引的实操要点与风险点
对百万级集合建索引会阻塞写入、占用大量内存和磁盘 I/O，不能直接在生产库上跑 createIndex：
- 加
{ background: true }参数：避免长时间锁表，例如db.fs.files.createIndex({ filename: 1, uploadDate: 1 }, { background: true }) - 避开业务高峰：即使后台建索引，仍会显著拉高 CPU 和磁盘负载，机械硬盘尤其明显
- 监控进度：用
db.currentOp({ "secs_running": { $gt: 60 } })查长时间运行操作，确认建索引是否卡住 - 别用
db.fs.files.ensureIndex()：该方法已弃用，且行为不一致
索引建好后，查询写法直接影响性能
有了索引，不代表所有查询都快——写法错，照样走不了索引：
- 必须用
db.fs.files.find()直接查，而不是依赖GridFS.find()封装层，后者在某些驱动版本中会额外加过滤条件导致索引失效 - 查询条件要严格匹配索引字段顺序：
{ filename: "log-20260423.txt", uploadDate: { $gte: ISODate("2026-04-23T00:00:00Z") } }能命中；但只查{ uploadDate: ... }就无法利用该复合索引 - 避免在
filename上用正则前缀模糊匹配：{ filename: { $regex: "^log-" } }无法使用索引，应改用固定前缀 + 范围查询，或引入全文索引 - 如果常按时间范围查（如最近7天上传的文件），单独为
uploadDate建个单字段索引更高效：db.fs.files.createIndex({ uploadDate: -1 })
索引不是建完就一劳永逸，filename 字段若存在大量重复值（比如全是 "temp.jpg"），复合索引的选择性会急剧下降，这时得结合业务逻辑加唯一约束或改用其他标识字段。
