MySQL联合索引最左匹配原则深度解析

核心结论：索引列顺序的重要性

在使用 MySQL 建立联合索引时，并非所有包含索引列的查询都能命中索引。以三字段的联合索引 (province, city, district) 为例，其本质是创建了以下三个索引结构：

• (province)
• (province, city)
• (province, city, district)

关键规则： 如果查询条件中跳过了中间字段（例如只使用 province 和 district），MySQL 只能利用最左侧的 province 进行过滤，而 district 无法直接利用索引定位，导致性能下降。

第1步：创建基础联合索引环境

为了验证这一现象，我们首先在表中建立一个覆盖三个字段的联合索引。这将作为后续测试的基础参照。

CREATE INDEX idx_abc ON user_address (province, city, district);

第2步：验证 AC 组合在 ABC 索引下的表现

在拥有 (province, city, district) 联合索引的前提下，执行仅包含首尾字段的查询。此时期望 MySQL 能利用索引，但事实往往相反。

SELECT * FROM user_address 
WHERE province = '广东' AND district = '南雄市';

查看该语句的执行计划（EXPLAIN）：

结果显示 type 为 ALL，表示进行了全表扫描。这说明虽然查询包含了索引中的字段，但由于跳过了中间的 city 字段，联合索引对 district 无效，整个联合索引未被充分利用。

第3步：优化方案——创建 AC 独立联合索引

既然业务逻辑经常需要按 province 和 district 查询，最直接有效的优化方法是针对这两个字段单独建立联合索引。注意，顺序依然遵循最左前缀原则。

SELECT * FROM user_address 
WHERE province = '广东' AND district = '南雄市';

再次观察执行变化：

查询结果变为 ref 类型，成功走了索引。扫描行数从之前的 21 行降低到 13 行，证明针对特定查询模式建立专用索引能显著提升效率。

第4步：AB 组合的常规验证

作为对照，验证连续的前缀字段查询（即 province 和 city）：

查询类型为 ref，符合预期。因为 A 和 B 是联合索引 (A,B,C) 的紧密前缀部分，完全命中索引。

深度思考：什么情况下索引会“中途停止”？

理解最左前缀原则不仅需要知道顺序，还需要了解边界条件。以下是两个关键的扩展场景：

1. 范围查询截断索引链

联合索引是从左向右匹配的，一旦遇到范围查询（如 >, <, BETWEEN, LIKE '%...'），后续的索引列将不再生效。

• 错误示例：若建索引 (a, b, c, d)，查询 a=3 AND b=4 AND c>5 AND d=6。由于 c 使用了范围条件，d 将无法使用索引。
• 正确调整：若将索引调整为 (a, b, d, c)，则 a, b, d 均等值匹配，只有最后的 c 因范围查询失效。这样整体利用率为 75%。

2. 等值查询的乱序优势

对于纯等值查询（= 或 IN），即使条件书写顺序与索引顺序不一致，MySQL 的查询优化器也会自动重排执行顺序。

• 例如：建索引 (a, b, c)，查询 b=2 AND a=1 AND c=3。
• MySQL 会将其优化为按 a→b→c 的顺序进行匹配，从而完美命中索引。

原理溯源：为什么必须“最左”？

联合索引的设计基于 B+ 树的排序特性。你可以将其想象为一本电话簿：

• 第一层排序（a）：首先按省份字母顺序排列。
• 第二层排序（b）：在同一个省份内，再按城市字母顺序排列。
• 第三层排序（c）：在同一个城市内，最后按街道/区县排列。

因此，如果你只知道“省”和“区”，却不知道“市”，数据库就无法直接进入“区”的那一页进行二分查找，只能先在“省”的范围内进行全盘扫描，这就导致了索引失效或效率低下。