MongoDB排序是否走索引，关键看explain中是否有SORT阶段——有则未真正利用索引排序；需确保sort字段顺序、方向与索引完全一致，且查询条件使相关字段实际参与范围裁剪。
怎么看 explain() 里有没有走索引排序
MongoDB 的排序是否真正利用索引，关键不是看有没有 IXSCAN，而是看执行计划中是否出现 SORT 阶段——只要它存在，说明 MongoDB 没法靠索引顺序直接返回结果，得额外内存或磁盘排序。
常见错误现象：查询加了 .sort({a: 1, b: -1})，但 explain("executionStats") 里却看到 "stage": "SORT"，同时 "nReturned" 远小于 "totalDocsExamined"，说明扫描了大量文档才挑出几条来排序。
- 必须确保 sort 字段顺序和索引字段顺序严格一致（包括方向），比如索引是
{a: 1, b: -1, c: 1}，那.sort({a: 1, b: -1})可以跳过SORT，但.sort({b: -1, a: 1})就不行 - 如果查询条件用了
$or、$in（多值）或范围查询（如{a: {$gt: 5}}）在前导字段上，即使有复合索引，也可能退化为先IXSCAN扫一堆，再SORT - 注意
limit()的位置：如果写成.find().sort().limit(10)，MongoDB 可能仍会排序全部匹配结果；而加上.hint()强制用某个索引，有时反而让优化器放弃排序优化
IXSCAN 阶段里的 indexBounds 和 direction 怎么读
IXSCAN 是索引扫描阶段，但它扫的是“键范围”不是“文档范围”。indexBounds 告诉你实际用了索引的哪一段，direction 表示扫描方向（1 = 正向，-1 = 逆向），这个方向必须和 sort 方向一致才能避免 SORT。
使用场景：当你怀疑排序没走索引，但 IXSCAN 确实出现了，就进 indexBounds 里看——如果 bound 是 {"a": [[1, 1]], "b": [["MinKey", "MaxKey"]]}，说明只靠 a 定界，b 没参与过滤，那 .sort({a: 1, b: -1}) 很可能还是得额外排序。
-
direction是IXSCAN自己的扫描方向，不是 sort 方向；只有当它和 sort 方向一致，且覆盖所有 sort 字段时，才能省掉SORT - 如果
indexBounds里某字段是["MinKey", "MaxKey"]或空数组，代表该字段在本次查询中没起到定界作用，别指望它帮排序 - 复合索引中非前导字段（如
{a: 1, b: 1}中只查b）会导致IXSCAN变成全索引扫描，direction失去意义
为什么加了索引还是出现 SORT 阶段
索引存在 ≠ 排序可用。MongoDB 要跳过 SORT，必须满足三个硬性条件：索引字段顺序与 sort 字段顺序完全一致、方向一致、且查询条件让这些字段在 IXSCAN 中实际参与了范围裁剪（即不是全扫）。
性能影响很明显：SORT 阶段默认在内存中做，但一旦超过 32MB（sort 内存限制），就会触发临时文件落盘，速度断崖式下降；更糟的是，它发生在 IXSCAN 之后，意味着已经读取并解码了大量文档。
- 聚合管道里用
$sort也一样受限制，不能指望靠后续$limit让优化器提前剪枝；必须让$sort字段能被上游索引原生支持 - 字符串排序要注意 collation：如果建索引时指定了
collation: {locale: "en"}，但查询没带对应 collation，索引无法用于排序，照样出SORT - 时间戳字段（
Date）用$dateToString后再 sort，等于放弃了索引排序能力——因为操作发生在文档层，不是索引键层
怎么验证排序真的走了索引（不靠肉眼猜）
最稳的方式是对比两个 explain("executionStats") 输出：一个带 sort()，一个去掉 sort()，看 "executionStages.stage" 是否从 IXSCAN → SORT → LIMIT 变成了纯 IXSCAN → LIMIT，同时 "totalDocsExamined" 是否显著下降（理想情况等于 "nReturned"）。
容易踩的坑是只看 stage 链条有没有 SORT，却忽略 "works" 和 "advanced" 的差值——如果 works 远大于 advanced，说明中间有大量“扫描但未命中”的键，本质仍是低效扫描。
- 用
.hint()强制指定索引后重新 explain，能排除优化器选错索引的干扰；但别长期依赖 hint，它绕过了统计信息，容易在数据分布变化后失效 - 对写多读少集合，考虑用
collation或部分索引（partialFilterExpression）缩小索引体积，让IXSCAN更精准，间接提升排序可行性 - 真正难缠的是多字段排序 + 范围查询混合场景，比如
.find({a: {$gte: 10}}).sort({a: 1, b: 1})——这时要看a的范围是否足够窄；否则即便结构合规，也会因扫描量过大被优化器放弃索引排序路径
排序能不能省掉 SORT 阶段，不取决于有没有索引，而取决于查询条件 + 排序字段 + 索引结构三者是否严丝合缝。差一个字段顺序、一个方向、一行 collation，就退回全量扫描+内存排序。线上查慢日志时，优先盯 executionStats.executionStages 里有没有 SORT，再往 IXSCAN.indexBounds 里钻细节。
