怎么通过MongoDB执行计划判断排序是否走了索引_SORT阶段与IXSCAN阶段分析-MongoDB-PHP中文网

mongodb排序是否走索引，关键看explain中是否有sort阶段——有则未真正利用索引排序；需确保sort字段顺序、方向与索引完全一致，且查询条件使相关字段实际参与范围裁剪。

怎么通过mongodb执行计划判断排序是否走了索引_sort阶段与ixscan阶段分析

怎么看 `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 里钻细节。