直接查 uploadDate 会慢是因为该字段默认无索引，导致时间范围查询触发全表扫描；需执行 db.fs.files.createIndex({ uploadDate: 1 }) 创建升序索引，并用 BSON Date 对象构造查询条件才能命中索引。
为什么直接查 uploadDate 会慢？
GridFS 的文件元信息存在 fs.files 集合里，uploadDate 是 BSON UTC datetime 类型字段，默认没索引。不建索引时，按时间范围查（比如最近7天）会触发全表扫描，尤其当文件数过万后，查询可能从毫秒级拖到几秒甚至超时。
怎么给 uploadDate 加升序索引？
在 MongoDB Shell 或 mongosh 里执行即可，不需要重启服务：
db.fs.files.createIndex({ uploadDate: 1 })
注意点：
-
uploadDate: 1表示升序；降序用-1，但时间范围查询升序更常用，B-tree 索引对范围扫描友好 - 索引名不用指定，MongoDB 自动命名（如
uploadDate_1），除非你后续要手动删 - 如果集合已有大量数据，建索引会阻塞写入（WiredTiger 引擎下是后台建索引，但仍占 I/O 和内存）
- 建完用
db.fs.files.getIndexes()确认索引状态，确保"status": "READY"
查询时怎么写才能命中索引？
必须用标准的 BSON date 对象构造范围条件，不能传字符串或数字时间戳：
db.fs.files.find({
uploadDate: {
$gte: new Date("2024-05-01T00:00:00Z"),
$lt: new Date("2024-05-08T00:00:00Z")
}
})
常见踩坑：
- 用字符串比较：
{ uploadDate: { $gte: "2024-05-01" } }→ 不走索引，字符串字典序 ≠ 时间顺序 - 用毫秒数：
{ uploadDate: { $gte: 1714521600000 } }→ 类型不匹配，索引失效 - 用
$where或聚合管道里的$dateToString→ 强制全表扫描，完全绕过索引 - 复合查询时把
uploadDate放在非前导位置，比如{ filename: "log.zip", uploadDate: { $gt: ... } }，但没给{ filename: 1, uploadDate: 1 }建复合索引 → 只能部分利用
要不要加复合索引？
取决于你的实际查询模式。如果总是按业务类型 + 时间查（比如 type: "report" 再加时间范围），那就该建：
db.fs.files.createIndex({ type: 1, uploadDate: 1 })
但注意：
- 每个索引都增加写入开销和磁盘占用，
fs.files本身字段少，单字段uploadDate索引性价比最高 - 如果
type基数极低（比如只有 2–3 个值），复合索引效果可能不如单独uploadDate索引 - 索引字段顺序很重要：等值查询字段放前面，范围查询字段放后面
真正容易被忽略的是时区处理——uploadDate 存的是 UTC，但业务时间范围常按本地时区算，别直接拿北京时间字符串去查，务必转成 UTC 时间对象再构造查询条件。
