复合索引中范围查询字段后的字段不能参与排序，因B+树仅保证前缀有序；$in多值、$gt/$lt等会使后续字段物理顺序不连续，导致排序无法下推至索引，需内存SORT。
复合索引中范围查询字段之后的字段，为什么不能参与排序
因为 MongoDB 的 B+ 树索引只保证「前缀有序」，一旦遇到范围查询（如 $gt、$lt、$in 非单值），后续字段在索引中的物理顺序就不再连续，无法提供稳定排序语义。
举个例子：索引 { status: 1, createdAt: -1, priority: 1 }，如果查询是 .find({ status: "active" }).sort({ createdAt: -1, priority: 1 })，能走索引排序；但换成 .find({ status: { $in: ["active", "pending"] } }).sort({ createdAt: -1, priority: 1 })，createdAt 和 priority 就大概率失效——执行计划里会出现 "stage": "SORT"。
-
$in多值匹配本质是多个等值查询的 OR 合并，MongoDB 会分别扫描每个值对应的索引子树，各子树内createdAt虽有序，但子树之间无序 -
$gt/$lt类范围条件会让索引扫描从某个键开始“一路往下”，但这个“往下”的路径只保障第一个字段单调，后续字段在跨块时完全可能跳变 - 即使
explain("executionStats")显示用了IXSCAN，只要看到"nReturned"远小于"totalKeysExamined"，且存在"stage": "SORT"，就说明排序没下推
哪些查询条件会让后续排序字段“断连”
不是所有非等值查询都必然破坏排序，但以下几种明确不可信：
-
$ne、$not：索引无法跳过不匹配项，必须全量读取再过滤，排序信息丢失 -
$regex（非前缀）：除非是^abc这种可利用索引前缀的写法，否则退化为集合扫描 -
$exists: true或$type：这类查询不提供值边界，索引无法定位起始/结束位置 -
$or表达式：即使每个子句都有索引，MongoDB 6.0+ 也仅支持用多个索引做 filter 合并，不支持跨索引构造联合排序顺序
注意：$in 单元素（如 { status: { $in: ["active"] } }）等价于等值查询，后续字段仍可排序；但只要数组长度 ≥2，就触发多路径扫描，排序能力归零。
如何验证排序是否真的走了索引
别信直觉，直接看执行计划。重点盯三个字段：
-
"stage"：出现"SORT"就代表内存排序已发生；理想情况应只有"IXSCAN"→"FETCH"（或直接"IXSCAN"如果是覆盖索引） -
"sortStage"：如果存在，检查其"works"是否为 0；非 0 说明有实际排序动作 -
"executionStages.works"总和 vs"nReturned"：若前者远大于后者，说明大量中间结果被丢弃，排序未下推
运行命令：db.collection.explain("executionStats").find({ status: { $in: ["active", "pending"] } }).sort({ createdAt: -1, priority: 1 })
真正能保排序的替代方案
当业务必须用范围查询又依赖后续字段排序时，显式拆分是唯一可靠路径：
- 把范围条件转为等值 + 应用层合并：比如
$in: ["A","B"]拆成两次查询status: "A"和status: "B"，各自用索引排序后，在内存 merge - 用时间窗口收窄范围：把
createdAt: { $gt: ISODate("2020-01-01") }改成dateBucket: "2020-Q1"这类离散字段，再建等值索引 - 加冗余排序字段：例如对高频范围查询字段
statusGroup（枚举为 "active_pending" / "closed_archived"），建索引{ statusGroup: 1, createdAt: -1, priority: 1 }，应用层映射原始状态到分组
最常被忽略的一点：索引字段顺序不能只按“查询习惯”排，而要严格按「等值字段 → 范围字段 → 排序字段」三级递进。哪怕只是把 createdAt 和 priority 对调，也会让整个排序链路崩掉。
