在 MongoDB 的性能优化体系中，索引是提升查询效率最核心的利器。当业务查询涉及多个字段时，单字段索引往往捉襟见肘，此时复合索引，Compound Index便成为破局的关键。然而，复合索引的设计并非简单的字段堆砌，其底层受限于 B+ 树的存储结构与“最左前缀原则”。
一、复合索引与最左前缀原则核心解析
复合索引是指包含多个字段并按特定顺序排列的索引。MongoDB 的复合索引底层采用 B+ 树数据结构，数据首先按照第一个字段排序，当第一个字段值相同时，再按照第二个字段排序，依此类推。
这种物理存储结构决定了复合索引必须遵循最左前缀原则（Leftmost Prefix Rule）：查询条件必须从索引的最左侧字段开始匹配，才能有效利用该索引。
以创建复合索引 {a: 1, b: 1, c: 1} 为例，该索引支持以下前缀查询：
- {a: 1}
- {a: 1, b: 1}
- {a: 1, b: 1, c: 1}
查询条件与索引命中情况对比表：
| {a: 1} | ✅ 命中 | 完美匹配最左前缀，通过索引直接定位。 |
| {a: 1, b: 1} | ✅ 命中 | 匹配前两个字段，索引利用率高。 |
| {a: 1, b: 1, c: 1} | ✅ 命中 | 匹配完整复合索引，效率最高。 |
| {b: 1} | ❌ 未命中 | 跳过了最左侧字段 a，导致索引完全失效，退化为全表扫描（COLLSCAN）。 |
| {b: 1, a: 1, c: 1} | ⚠️ 部分命中 | 虽然包含了索引的所有字段，但查询条件中的顺序无关紧要。MongoDB 内部会自动将其重写为 {a: 1, b: 1, c: 1}。因此，它能完美命中完整索引，效率极高。 |
| {a: 1, c: 1} | ⚠️ 部分命中 | 仅利用了最左前缀 a，由于跳过了中间字段 b，c 的过滤条件只能在内存中进行（IXSCAN + FETCH）。 |
| sort({a: 1, b: 1}) 配合索引 {a: 1, b: -1} | ❌ 排序失效 | 最左前缀匹配，但排序方向不一致。 索引在 a 相同的情况下是 b 降序，无法满足 b 升序的排序需求，会导致内存排序（Filesort）。 |
核心差异：MongoDB vs MySQL 的最左前缀原则
虽然 MongoDB 和 MySQL 都遵循“最左前缀原则”，但在底层实现和查询优化器上有着本质的区别：
1. 查询条件的顺序：严格匹配 vs 智能重写
- MySQL：在 MySQL 版本中，如果查询条件写成了 WHERE b = 1 AND a = 1 AND c = 1，优化器也可以很好地利用 {a, b, c} 的索引。
- MongoDB：MongoDB 的查询优化器极其聪明。它完全不关心你传入的查询条件对象的键值对顺序。因为 MongoDB 的 BSON 文档在内存中会被解析为哈希表（或类似结构），当你传入 {b: 1, a: 1, c: 1} 时，MongoDB 在内部执行计划生成阶段，会自动将其重写为 {a: 1, b: 1, c: 1}，以完美对齐复合索引 {a: 1, b: 1, c: 1}。因此，在 MongoDB 中，等值查询条件的书写顺序永远不会影响索引的命中。
2. 索引跳跃扫描（Index Skip Scan）
- MySQL：从 MySQL 8.0 开始引入了“索引跳跃扫描”（Index Skip Scan）。即使查询条件只有 {b: 1}（跳过了最左侧的 a），如果 a 字段的区分度（Cardinality）非常低（比如只有男、女两种值），MySQL 优化器会将其拆解为 a='男' AND b=1 和 a='女' AND b=1 多次扫描，从而依然能够利用到 {a, b} 索引。
- MongoDB：MongoDB 目前不支持索引跳跃扫描。如果查询条件跳过了最左侧字段（如仅查询 {b: 1}），MongoDB 绝不会去利用 {a: 1, b: 1} 索引，而是直接退化为全表扫描（COLLSCAN）。这意味着在 MongoDB 中，最左前缀原则的执行比 MySQL 更加严格和绝对。
3. 排序方向（Sort Direction）的敏感度
- MySQL：MySQL 的 B+ 树索引在物理存储上通常是单向的，但 MySQL 优化器支持反向扫描（Backward Index Scan）。因此，对于 {a: 1, b: 1} 的索引，MySQL 同样可以完美支持 ORDER BY a DESC, b DESC。
- MongoDB：MongoDB 的复合索引在创建时严格绑定排序方向。索引 {a: 1, b: -1} 可以支持 sort({a: 1, b: -1}) 和 sort({a: -1, b: 1})（整体反向扫描），但绝对无法支持 sort({a: 1, b: 1})。如果在 MongoDB 中需要支持双向排序，必须显式创建两个方向的复合索引。
二、底层原理图解：最左前缀匹配过程
以下流程图展示了 MongoDB 在处理查询条件时，如何遍历复合索引的 B 树：
从图中可以清晰看出，B+ 树的查找是一个逐级收敛的过程。一旦在查询条件中“跳过”了某个中间字段，后续的字段在 B+ 树中便失去了全局有序性，从而无法继续利用索引进行范围扫描。
三、进阶设计：遵循 ESR 最佳实践
在实际业务中，查询往往同时包含等值过滤（Equality）、排序（Sort）和范围过滤（Range）。为了让复合索引发挥最大效能，字段顺序的设计必须遵循 ESR 规则：
实战案例：
假设查询需求为：“查找特定客户（等值）、状态为已发货（等值），按订单时间降序排列（排序），且价格在 100-500 之间（范围）的订单。”
db.orders.find({
customerId: "cust123", // E: 等值
status: "shipped", // E: 等值
price: { $gte: 100, $lte: 500 } // R: 范围
}).sort({ orderDate: –1 }); // S: 排序
最优索引设计：
db.orders.createIndex({
customerId: 1, // E – 等值
status: 1, // E – 等值
orderDate: –1, // S – 排序
price: 1 // R – 范围
});
错误示范：若将 price 放在 orderDate 前面（即 {customerId, status, price, orderDate}），MongoDB 在扫描完 price 的范围后，将无法利用 orderDate 的索引排序，只能在内存中对结果集进行排序，当数据量庞大时会导致严重的性能瓶颈。
四、高频面试题
Q1：在复合索引 {a:1, b:1, c:1} 中，查询条件为 {a: 1, c: 1}，索引会完全失效吗？
答： 不会完全失效。根据最左前缀原则，MongoDB 会利用索引的最左前缀 {a: 1} 进行索引扫描（IXSCAN），快速定位到 a=1 的数据。但是，由于跳过了中间字段 b，c 的条件无法在索引层面进行过滤，MongoDB 会在内存中拉取 a=1 的所有文档，然后再通过 FETCH 阶段在内存中过滤 c=1 的记录。因此，索引是“部分命中”的。
Q2：为什么 ESR 规则要求范围查询（Range）必须放在排序（Sort）和等值（Equality）之后？
答： 因为 B+ 树的有序性是逐级递减的。当遇到范围查询（如 a > 10）时，a 字段在索引中不再是一个确定的点，而是一个区间。在这个区间内，后续字段（如排序字段）虽然相对有序，但全局已不再有序。如果将范围字段放在排序字段前面，MongoDB 将无法直接通过索引获取排好序的数据，从而被迫在内存中进行 Filesort，导致性能急剧下降。
Q3：对于区分度（Cardinality）极低的字段（如 gender 性别字段），是否应该放在复合索引的最左侧？
答： 通常不建议。虽然最左前缀原则要求从最左侧开始匹配，但将区分度极低的字段放在最左侧，会导致单次索引扫描返回大量数据，失去了索引“快速过滤”的意义。在遵循 ESR 规则的前提下，如果该字段仅用于等值查询且区分度极低，应尽量将其放在高区分度等值字段之后；如果它仅用于范围查询或排序，则应严格遵循 ESR 规则放置在相应位置。
Q4：MongoDB 的复合索引是否支持反向扫描？
答： 支持。对于单字段索引，升序（1）和降序（-1）没有区别，因为 MongoDB 可以双向遍历 B+ 树。但对于复合索引，排序方向至关重要。例如，索引 {a: 1, b: -1} 可以完美支持 sort({a: 1, b: -1}) 和 sort({a: -1, b: 1})（通过反向扫描索引），但无法支持 sort({a: 1, b: 1})，因为索引在 a 相同的情况下，b 是降序存储的，无法直接满足 b 的升序排序需求。
