对日期字段建单字段索引通常够用，但必须显式sort()且方向一致才能避免全表扫描或额外sort阶段；带等值条件时应改用复合索引，等值字段在前、日期字段在后。
直接回答：对日期字段建单字段索引（如 created_at: 1）通常就够用，但必须配合 sort() 显式声明顺序，否则 MongoDB 可能不走索引做排序；若查询还带其他等值条件（如 status: "done"），应改用复合索引并把等值字段放前、日期字段放后。
为什么 find({ created_at: { $gte: ISODate("..."), $lt: ISODate("...") } }) 仍可能全表扫描
现象：明明有 created_at 索引，执行计划里却显示 "stage": "COLLSCAN" 或 "stage": "IXSCAN" 后紧跟 "stage": "SORT"（非内存排序，而是因索引未覆盖排序需求）。
原因不是索引没建，而是查询语句没触发索引的排序能力——MongoDB 只有在「索引顺序能天然满足查询的 sort 顺序」时，才复用索引完成排序；否则它宁可走索引查出所有匹配文档，再额外排序（SORT 阶段），甚至退化为全表扫（尤其当范围过大、选择性低时）。
- 单字段日期索引
{ created_at: 1 }只能高效支持按升序遍历；若你写.sort({ created_at: -1 })，它无法反向利用该索引，可能跳过索引或引入内存排序 - 如果查询中还有
.limit(10)却没sort()，MongoDB 不保证返回顺序，优化器也可能放弃用索引加速范围查找 - 日期范围太宽（比如查“过去一年”但集合有十年数据），索引选择性下降，优化器可能判定全表扫描更快
如何让日期范围查询真正走索引并避免 SORT 阶段
核心是让 IXSCAN 同时承担「过滤 + 排序 + limit 跳过」三重职责。这要求查询结构与索引方向严格对齐：
- 建索引时明确方向：
db.logs.createIndex({ created_at: 1 })（升序）→ 查询必须用.sort({ created_at: 1 })；若常用降序，就建{ created_at: -1 }并统一用.sort({ created_at: -1 }) -
sort()必须显式写出，且方向与索引一致；不能依赖默认顺序，也不能省略 - 加
limit()能显著提升效率——索引 B-Tree 可直接按顺序取前 N 条，无需捞出全部范围结果再截断 - 验证是否生效：用
.explain("executionStats")查看输出中"nReturned"是否接近"limit"值，且"executionStages.stage"里只有"IXSCAN"，没有"SORT"或"COLLSCAN"
示例有效写法：
db.logs.find({
created_at: {
$gte: ISODate("2025-01-01T00:00:00Z"),
$lt: ISODate("2025-02-01T00:00:00Z")
}
}).sort({ created_at: 1 }).limit(20).explain("executionStats")
什么时候必须升级为复合索引
单字段日期索引在以下场景会失效或低效，必须改用复合索引：
- 查询带固定等值条件，例如
find({ status: "success", created_at: { $gte: ..., $lt: ... } })—— 此时应建{ status: 1, created_at: 1 }，把status放前（高选择性等值字段），created_at放后（范围/排序字段） - 既要按日期范围查，又要按另一字段排序（如
.sort({ updated_at: -1 })），而updated_at和created_at不同——这时得权衡：要么建{ status: 1, created_at: 1, updated_at: -1 }覆盖全部，要么接受部分阶段无法索引加速 - 查询含数组字段（如
tags: { $in: ["api", "error"] }），且需结合日期范围——多键索引 + 复合结构更稳妥，单字段日期索引大概率被忽略
注意：复合索引中日期字段的位置决定了它能否用于范围和排序；放在最后才可被 $gte/$lt 利用，放在中间或开头则只能用于等值匹配。
容易被忽略的细节和坑
真实线上环境里，最常栽跟头的地方不在语法，而在数据特征和操作习惯：
-
ISODate()字符串格式错误会导致查询不命中索引（例如传了字符串"2025-01-01"而非ISODate(...)），explain里会看到"indexBounds"为空或异常 - 时间字段存的是字符串（如
"2025-01-01 12:00:00"）而非Date类型——索引完全无效，必须先用聚合管道转换类型并重建数据 - 后台建索引（
{ background: true }）虽不阻塞写入，但耗时更长、资源占用更高；生产环境建大集合索引务必选低峰期，否则可能拖慢副本集同步 - 索引名默认由字段+方向生成（如
created_at_1），但手动指定name选项更利于后续维护和监控（比如用db.collection.getIndexes()快速识别用途）
最麻烦的情况是：你以为用了索引，explain 显示走了 IXSCAN，但 "executionTimeMillis" 依然很高——大概率是索引条目太多（日期范围太宽），B-Tree 深度增加或磁盘 IO 上升，这时得考虑 TTL 索引自动归档旧数据，或按月分片预拆分集合。
