多字段排序慢的本质是索引无法覆盖完整排序路径；必须严格遵循esr原则（等值→排序→范围）构建复合索引，且排序字段方向须与sort()完全一致，否则触发内存排序并可能报错。
多字段排序为什么慢？本质是索引无法覆盖排序路径
MongoDB 对 sort() 的支持高度依赖索引顺序。当查询同时按 {a: 1, b: -1, c: 1} 排序时，若索引是 {a: 1, b: 1, c: 1}，MongoDB 只能利用前缀 a 和 b（因 b 方向不匹配），c 字段排序将触发内存中的 in-memory sort，一旦数据量稍大就容易触发 QueryExceededMemoryLimitNoDiskUseAllowed 错误。
ESR 原则不是教条，而是索引字段顺序的硬约束
ESR（Equality → Sort → Range）不是建议，是 MongoDB 索引使用机制决定的物理限制：只有严格满足该顺序，索引才能被完整用于过滤 + 排序。违反它，排序部分就会失效。
-
Equality 字段：如
{status: "active"}，必须放在最左，且方向任意（1或-1都可，因等值匹配不关心方向） -
Sort 字段：如
{createdAt: -1, score: 1}，必须紧接 Equality 后，且方向必须与sort()完全一致（-1就不能用1索引） -
Range 字段：如
{price: {$gt: 100}}，只能放最后，且仅支持一个（多个 range 会截断索引使用）
例如，查询：db.orders.find({status: "shipped", category: "electronics"}).sort({createdAt: -1, score: 1}).limit(20)，对应正确索引是 {status: 1, createdAt: -1, score: 1, category: 1} —— 注意 category 是等值但放后面了？不行。必须调整为 {status: 1, category: 1, createdAt: -1, score: 1}，否则 category 会被当 range 处理，导致排序失效。
复合索引方向不匹配的典型报错和验证方法
执行 explain("executionStats") 后重点看两个字段：executionStats.totalKeysExamined 是否远大于 executionStats.nReturned；以及 executionStats.executionStages.stage 是否出现 SORT（而非全部由 IXSCAN 完成）。出现 SORT 即表示排序未走索引。
- 错误索引：
{a: 1, b: 1}支持.sort({a: 1, b: 1})，但不支持.sort({a: 1, b: -1}) - 正确写法：要支持混合方向排序，索引必须显式声明对应方向，如
{a: 1, b: -1} - 注意：MongoDB 5.0+ 支持在单个索引中混合方向（如
{a: 1, b: -1, c: 1}），但旧版本（
验证命令示例：
db.orders.find({status: "paid"}).sort({updatedAt: -1, amount: 1}).explain("executionStats")
排序字段过多或含数组时，索引会静默失效
MongoDB 不支持对数组字段做多字段排序索引——只要 sort() 中任一字段是数组（如 tags: ["a", "b"]），即使建了 {tags: 1, createdAt: -1}，排序阶段也会退化为内存排序。这是设计限制，不是配置问题。
- 规避方式：避免在
sort()中直接使用数组字段；如需按标签相关性排序，应预计算标量值（如tagScore: 0.87）并对此字段建索引 - 另一个陷阱：排序字段包含
$text查询结果时，sort()完全不可加速，必须靠应用层处理 - 内存限制真实存在：
sort()操作默认最多使用 100MB 内存（maxSortMemoryUsageBytes），超限即报错，无法自动落盘
真正难的不是建索引，而是识别出哪些“看似合理”的排序组合，其实根本没法被索引覆盖。动手前先 explain，比翻文档更可靠。
