MySQL 的联合索引是优化查询性能的利器，但要用好它，必须理解一个核心概念——最左前缀原则。这个原则不仅是面试中的高频考点，更是日常 SQL 优化中绕不开的基石。本文将从实际应用出发，系统梳理最左前缀原则的工作机制、典型场景以及容易踩坑的边界情况。
一、什么是最左前缀原则
联合索引在 B+ 树中是按照索引列的定义顺序依次排序的。以 idx_a_b_c (a, b, c) 为例，数据首先按 a 排序，a 相同再按 b 排序，b 相同再按 c 排序。这种结构决定了查询必须从索引的最左列开始，才能有效利用索引的有序性。
简单来说：查询条件必须包含联合索引的最左列，且不能跳过中间列，才能触发索引的完整或部分使用。
二、典型应用场景
2.1 全列匹配
SELECT * FROM t WHERE a = 1 AND b = 2 AND c = 3;
三个条件全部命中，索引被完整使用，效率最高。注意 WHERE 子句中的书写顺序不影响优化器对索引的选择，优化器会自动调整匹配顺序。
2.2 最左列匹配
SELECT * FROM t WHERE a = 1;
只用到索引的第一列 a，依然能走索引，只是无法利用 b、c 的有序性。
2.3 最左前缀匹配（范围查询）
SELECT * FROM t WHERE a = 1 AND b > 2 AND c = 3;
这里 a 是等值匹配，b 是范围匹配。索引能用到 a 和 b，但 c 无法再走索引查找，因为 b 的范围扫描导致后续列的有序性被破坏。c = 3 只能在回表后作为过滤条件（Using where）。
2.4 覆盖索引场景
SELECT a, b, c FROM t WHERE a = 1 AND b = 2;
查询列全部包含在索引中，无需回表，Extra 显示 Using index，性能极佳。
三、边界情况深度剖析
3.1 跳过最左列
SELECT * FROM t WHERE b = 2 AND c = 3;
缺少最左列 a，索引完全无法使用，退化为全表扫描。这是最典型的失效场景。
3.2 中间列断档
SELECT * FROM t WHERE a = 1 AND c = 3;
a 能用索引，但 b 缺失导致 c 无法利用索引有序性。c = 3 只能作为回表后的过滤条件。此时索引使用程度仅到 a。
3.3 LIKE 查询的陷阱
-- 能用索引（前缀匹配）
SELECT * FROM t WHERE a LIKE 'abc%';
-- 不能用索引（以 % 开头）
SELECT * FROM t WHERE a LIKE '%abc';
LIKE 'abc%' 本质上是范围查询，符合最左前缀；而 LIKE '%abc' 无法确定起始位置，索引失效。
3.4 范围查询后的列失效
这是面试中最容易出错的一点：
SELECT * FROM t WHERE a > 1 AND b = 2 AND c = 3;
a > 1 是范围条件，索引只能用到 a 列。b、c 因为 a 的有序性被范围扫描破坏，无法继续走索引查找。很多人误以为 b = 2 是等值匹配就能用上索引，实际上在范围列之后的等值条件都会失效。
3.5 ORDER BY 与最左前缀
-- 能用索引排序
SELECT * FROM t WHERE a = 1 ORDER BY b, c;
-- 不能完全用索引排序（b 是范围，c 排序失效）
SELECT * FROM t WHERE a = 1 AND b > 2 ORDER BY c;
-- 排序方向不一致也会失效
SELECT * FROM t WHERE a = 1 ORDER BY b ASC, c DESC;
ORDER BY 要利用索引，同样需要满足最左前缀，且排序方向需一致（MySQL 8.0 之前）。
3.6 索引条件下推（ICP）
MySQL 5.6 引入的 Index Condition Pushdown 优化，让部分本应在 Server 层过滤的条件下推到存储引擎层。例如：
SELECT * FROM t WHERE a = 1 AND b > 2 AND c = 3;
开启 ICP 后，c = 3 会在索引层面先做一次过滤，减少回表次数。但注意，ICP 并没有改变最左前缀原则，c 依然无法用于索引定位，只是减少了回表的数据量。Extra 中会显示 Using index condition。
3.7 隐式类型转换
-- a 是 varchar 类型
SELECT * FROM t WHERE a = 1;
当字符串列与数字比较时，MySQL 会将字符串转为数字，相当于对索引列做了函数操作，导致索引失效。这是实际生产环境中非常隐蔽的坑。
四、面试高频问题
Q：联合索引 (a, b, c)，WHERE a = 1 AND c = 3 能用索引吗？
A：能用到 a 列，c 无法用于索引查找，只能回表后过滤。索引使用不完整。
Q：WHERE b = 2 AND a = 1 AND c = 3 能用索引吗？
A：能。优化器会自动调整顺序，等价于 a = 1 AND b = 2 AND c = 3，全列匹配。
Q：WHERE a > 1 AND b = 2 能用索引吗？
A：只能用到 a，b 无法用于索引查找。范围列之后的列失效。
Q：为什么范围查询后面的列会失效？
A：因为 B+ 树中，只有在前面列等值确定的情况下，后续列才是有序的。范围扫描导致后续列在扫描区间内无序，无法进行二分查找。
五、实践建议
- 联合索引列顺序：等值查询列放前面，范围查询列放后面，区分度高的列优先。
- 避免跳过最左列：设计查询时确保最左列出现在 WHERE 中。
- 警惕隐式转换：确保查询条件类型与列类型一致。
- 善用 EXPLAIN：通过
key、key_len、Extra判断索引实际使用情况。 - 覆盖索引优先：能走覆盖索引就不回表，减少随机 IO。
总结
最左前缀原则的本质是 B+ 树的有序性约束。理解它不仅要记住“从最左列开始、不能跳过中间列”的口诀，更要深入理解范围查询后列失效、ORDER BY 排序失效、ICP 优化边界等细节。在实际工作中，结合 EXPLAIN 分析执行计划，才能设计出真正高效的索引方案。
未经允许不得转载：任鹏个人博客 » MySQL 最左前缀原则：联合索引的实战应用与边界情况
