MongoDB索引排序失效的根本原因是索引字段顺序不满足ESR原则及连续前缀要求：排序字段必须位于查询条件最左连续前缀的最右端，且方向一致；若范围字段在排序字段左侧、或缺失最左字段、或多键索引冲突，均会触发内存SORT。
当你确认查询条件和排序字段都包含在某个复合索引中，执行 explain("executionStats") 也显示用了 IXSCAN，但响应依然缓慢、甚至报出 Exceeded memory limit for $sort，说明 MongoDB 实际仍在内存中完成排序——这并非索引没被选中，而是索引未被用于排序。
根本原因：索引字段顺序与查询模式不匹配
MongoDB 只能利用索引的**连续前缀**支撑排序，且排序字段必须位于该前缀的**最右端连续段**。哪怕索引里包含所有用到的字段，只要顺序或方向错一位，SORT 阶段就会出现。
例如索引为 {userId: 1, status: 1, createdAt: -1}：
✅ 查询 db.orders.find({userId: "U123", status: "paid"}).sort({createdAt: -1}) 能走索引排序；
❌ 查询 db.orders.find({userId: "U123"}).sort({status: 1, createdAt: -1}) 会触发内存排序——因为 status 和 createdAt 在索引中虽存在，但不是从最左连续字段开始构成的排序前缀（缺少 userId 条件时，status 就不再是前缀起点）。
排序方向不一致导致索引失效
方法一：严格比对 sort() 中的方向与索引定义
如果索引是 {a: 1, b: 1}，则只支持 .sort({a: 1, b: 1}) 或全反向 .sort({a: -1, b: -1})；.sort({a: 1, b: -1}) 无法利用该索引排序。
方法二：检查 explain 输出中的 inputStage
执行 db.orders.find({...}).sort({...}).explain("executionStats")，重点看 executionStats.executionStages.inputStage.stage —— 如果它的值是 SORT，就证明 MongoDB 在 IXSCAN 之后又做了一次内存排序，索引的排序能力完全没被调用。
【关键陷阱】 多键索引（数组字段）上排序极易触发内存排序：除非所有排序字段的索引边界都是 [MinKey, MaxKey]，且无多键字段路径与排序前缀重合，否则强制 fallback 到内存。
范围字段位置错误打断排序连续性
第一步：识别查询中是否存在范围操作符（$gt、$lt、$in、$regex 等）
第二步：确认该字段是否排在排序字段之前
第三步：若范围字段在排序字段左侧，立即调整索引顺序——ESR 原则要求范围（R）必须在排序（S）之后。例如查询 db.logs.find({service: "api", level: {$in: ["error"]}}).sort({timestamp: -1})，索引必须为 {service: 1, timestamp: -1, level: 1}，而非 {service: 1, level: 1, timestamp: -1}。
一旦范围字段出现在排序字段之前，B-tree 中该范围区间内的 timestamp 就不再全局有序，MongoDB 别无选择，只能取出全部匹配文档再内存排序。
这一步操作起来很简单，直接改索引字段顺序再重建即可，但重建前务必停写或使用后台方式（background: true），避免锁表。
查询条件未覆盖索引最左前缀
方法一：检查 find() 中是否遗漏了索引最左字段
比如索引是 {region: 1, userId: 1, score: -1}，但查询只写了 {userId: "U100"}.sort({score: -1})，那就只用到 userId 这个单字段前缀，score 排序无法复用索引顺序。
方法二：用 hint() 强制走索引，再看 explain
执行 db.coll.find({...}).sort({...}).hint({"region": 1, "userId": 1, "score": -1}).explain("executionStats")，如果此时 inputStage.stage 仍是 SORT，说明问题不在是否选索引，而在索引结构本身不满足排序需求。
注意：hint 不解决根本问题，仅用于排除“优化器误选索引”的干扰。
验证索引是否真正支撑排序
① 运行完整 explain 命令：db.orders.find({status: "shipped", userId: 123}).sort({createdAt: -1}).explain("executionStats")
② 定位 executionStats.executionStages.stage → 必须为 IXSCAN
③ 定位 executionStats.executionStages.inputStage → 不能存在 stage: "SORT"
④ 检查 executionStats.totalDocsExamined 是否等于 executionStats.nReturned —— 若前者远大于后者，说明索引过滤效率低，可能因范围字段前置或选择性差导致大量无效文档被扫描后又被丢弃。
这一步做完，就能明确知道是索引建错了，还是查询写错了。
