最左前缀原则：联合索引失效的根因与实战排查

前一阵帮同事排查一个慢查询，他给一张将近千万行的表建了个联合索引，建完以后跑了一下，发现查询还是慢得要命。他拿着EXPLAIN结果来找我，嘴上还念叨着：“索引我建了啊，为什么没生效？”我看了一眼他建的表，索引是(a, b, c)三列联合索引，SQL的WHERE条件里写的是WHERE b = 'xxx'，当时我就知道问题出在哪了——这几乎是我见过最典型的“最左前缀原则没真正理解”的案例。

这篇文章不打算把最左前缀原则当教科书来讲，我想从存储结构、实测验证、常见误区和实际调优这几个角度把它彻底说透，顺便把我在排查过程中踩过的坑、总结的经验一并放出来。你如果之前只是背过“查询要从最左列开始”这句话，却说不清为什么，或者遇到过“明明有索引却不走”的情况，那这篇应该能帮上忙。

1. 最左前缀原则到底在说什么

1.1 三句话先建立正确直觉

我对最左前缀原则的完整理解，可以压缩成三句话：

• 联合索引在B+树里是按“定义列的顺序”逐级排序的，所以查询条件必须能匹配上“从最左列开始的一段连续前缀”。
• 查询条件里哪怕缺了中间某一列，后面的列也没办法继续参与索引定位。
• 一旦某列用了范围查询，它右边的列就无法继续用索引精确定位了。

这三句话看着简单，但真到写SQL的时候，很多人会忘。尤其是“连续前缀”和“范围断链”这两个细节，几乎每次培训都能看到有人栽在上面。

1.2 联合索引在B+树里的排序规则

要理解最左前缀原则，先得搞清楚联合索引在B+树里到底是怎么存的。InnoDB的主键索引叶子节点存的是整行数据，普通二级索引叶子节点存的是“索引列 + 主键值”。联合索引也一样，只不过叶子节点里存的是多列的值。

关键在于排序规则。拿(a, b, c)联合索引举例，B+树内部并不是把三列拼接成一个字符串再排序，而是先按a排序；a相同的行，再按b排序；a和b都相同的行，最后按c排序。这个排序规则决定了索引的“可搜索性”。

打个生活化的比方：你有一本按“姓氏 + 名字”排序的电话簿，先按姓氏排，同姓氏的再按名字首字母排。这时候你想找“张小明”，可以直接翻到“张”的区域，再在“张”的区域里找“小明”。但如果你只知道“小明”，想在整本电话簿里快速定位，就没办法了，因为“小明”这个信息不能帮你锁定任何一段连续区域。

把电话簿换成B+树，道理完全一样。(a, b, c)索引只有在查询条件携带a时，才能利用B+树的“按a有序”的特性直接定位；只有a还不够，想继续缩小范围，还得带上b；想进一步精确定位，还得带上c。这就是“最左”二字的来源——它永远是从索引定义的最左列开始，往右一段连续的路。

1.3 为什么“必须从最左开始”是结构决定的

很多人会把最左前缀原则当成一条“数据库规定”，觉得背下来就行。其实不是规定，是B+树存储结构推导出来的必然结果。

B+树叶子节点之间的双向链表是有序的，但这个有序是“在a有序基础上，b局部有序；在a、b有序基础上，c局部有序”。一旦查询条件里没有a，等于你失去了整个树的“总排序依据”。你想用b来定位，但全表里b相同的行散落在各个不同的a区间里，B+树没法告诉你“从哪条记录开始扫描”。所以优化器只能选择全表扫描或者放弃这个索引。

这就是为什么MySQL里对“是否走索引”的判断，不看你SQL里写了几个条件，而是看这些条件能不能从联合索引的最左列开始，形成一段连续的前缀匹配。理解了这一层，后面所有看起来诡异的“索引失效”现象，基本都能自己推出来。

2. 用实测数据验证：什么样的SQL能命中索引

2.1 准备一张表，插入10万条测试数据

光讲理论容易飘，我习惯用实际数据说话。下面这张表结构很简单，但足够把最左前缀原则的几种情况测出来。

sql复制CREATE TABLE test_index (
  id INT PRIMARY KEY AUTO_INCREMENT,
  a INT NOT NULL,
  b VARCHAR(50) NOT NULL,
  c DATETIME NOT NULL,
  d DECIMAL(10, 2),
  KEY idx_a_b_c (a, b, c)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

测试数据我一般用存储过程批量插入，10万条足够看出区分度，又不会让操作等太久。

sql复制DELIMITER $$
CREATE PROCEDURE insert_test_data()
BEGIN
  DECLARE i INT DEFAULT 1;
  WHILE i <= 100000 DO
    INSERT INTO test_index (a, b, c, d)
    VALUES (
      FLOOR(RAND() * 1000),
      CONCAT('value_', FLOOR(RAND() * 1000)),
      NOW() - INTERVAL FLOOR(RAND() * 365) DAY,
      RAND() * 1000
    );
    SET i = i + 1;
  END WHILE;
END$$
DELIMITER ;

CALL insert_test_data();

a的取值范围是0到999，所以每个值大概有100条记录，区分度适中，比较符合真实业务里的普通枚举字段。

2.2 六种典型SQL逐条EXPLAIN

下面这组EXPLAIN结果是我在MySQL 8.0上跑出来的，直接看结论。

前三条比较好理解，从最左列开始逐级匹配，条件给得越多，key_len越长，说明用到的索引列越多。第四条是很多人容易忽略的：b用了范围查询之后，c就算给了等值条件，也无法继续参与索引定位，Extra里出现的Using index condition是另一回事，后面会专门讲。第五条等于在说“查询条件里没有最左列a”，整个联合索引都失去了意义。

2.3 key_len怎么读：判断你到底用了哪几列

判断一条SQL到底用到了联合索引的哪几列，最直观的办法是看EXPLAIN结果里的key_len。key_len表示优化器实际使用的索引字节长度，它不会多算，也不会少算。

计算方法其实不复杂，记住几个常见类型的基础长度就行：

• INT：4字节，NOT NULL不加额外标记，允许NULL再加1字节。
• VARCHAR(n)：如果是utf8mb4字符集，一个字符最多4字节，再加上存储实际长度的2个字节，所以一般是4n + 2。
• DATETIME：5字节，允许NULL再加1字节。
• CHAR(n)：utf8mb4下为4n字节，无额外的长度字节。

用上面的表验证，a是INT NOT NULL，长度是4。第二条SQL里用了a和b两列，b是VARCHAR(50)，50乘以4加2等于202，加在一起是206。但EXPLAIN显示的是38，这里需要注意，我表里b列的字符集虽然是utf8mb4，但VARCHAR(50)因为字符集实际是utf8mb4，理论长度应该是202，为什么是38呢？

这里我稍微修正一下刚才的说法，EXPLAIN里的key_len显示的是“优化器认为本次查询使用到的索引前缀长度”，它和列的完整定义长度不一定相同。比如b列从VARCHAR(50)里实际只需要匹配到'value_100'这9个字符，但MySQL的key_len计算是按列定义来的，不会按实际值长度动态缩小。

如果你在自己环境里测出来和我的数字不完全一致，先检查三件事：列是否允许NULL、字符集是utf8mb4还是utf8mb3、VARCHAR实际定义长度。key_len的目的不是背值，而是对比——同一条SQL，走a列时key_len=4，走a+b时key_len明显变大，就能确认索引多用了一层。

3. 四个“没真正理解”的常见误区

3.1 误区一：最左前缀 = SQL里最左边的列

这个误区出现频率最高。很多人以为最左前缀指的是“WHERE条件里写在最左边的列”，于是为了命中索引，特意把a放在WHERE子句的第一个位置，觉得这样就能用上索引。

实际上，MySQL优化器对等值条件会做基于成本的等价变换。你把条件写成WHERE c = '2024-01-01' AND b = 'value_100' AND a = 100，优化器照样能识别出a、b、c，完全不看书写顺序。最左前缀里的“最左”，永远指索引定义里最左侧的列，不是SQL语句里最左侧的列。

举一个我实际见过的错误写法。有人建了(user_id, status, created_at)索引，业务代码里拼SQL时动态拼接条件，把status放在前面、user_id放在后面，然后担心“顺序不对索引会失效”。其实完全多虑了，只要user_id在条件里，优化器能自动调整等值条件顺序。真正要担心的是“条件里没有user_id”，那才是彻底失效。

3.2 误区二：跳过中间列，后面的列还能继续用

这个误区比第一个更隐蔽。有人知道“查询要从最左列开始”，看到WHERE a = 100 AND c = '2024-01-01'，觉得“有a打头阵，也能用上索引”。对，a确实用上了索引，但c并没有参与索引定位。

原因还是回到B+树的排序规则。在(a, b, c)索引里，排序是先a后b再c。查询条件里的a=100可以定位到一段a=100的连续区间，但在这段区间里，数据只按b排好序，c的有序性只在b相同的前提下才成立。你现在跳过了b，直接按c去查，等于在“a=100的区间里”盲目找某一堆c值，无法用二分查找缩小范围。

这种情况的表现是：type=ref，key_len=4，说明优化的执行计划确实用了idx_a_b_c，但只用到了a这一列。c条件不是“完全没用”，而是在回表取出数据后，由Server层做二次过滤，Extra里会出现Using where，但这和“利用索引定位c”是两码事。

3.3 误区三：范围查询后面的列还能精确定位

这是联合索引使用里最经典的一个坑，也是面试里最爱考的点。WHERE a = 100 AND b > 'value_100' AND c = '2024-01-01'，到底能不能用上c？

答案是：c用不上索引定位。当b走范围查询时，存储引擎在a=100的区间内，会扫描所有b> 'value_100'的记录。而这些记录里的c虽然整体上不保证有序——因为c的有序性是建立在a、b都相同的前提下，现在b是一个范围，c在这个范围内是乱序的。所以c=某个值无法通过B+树的二分定位，只能把每条记录取出来逐一判断。

但这里有个非常容易迷惑人的地方：在MySQL 8.0里，执行计划可能显示Extra为Using index condition。很多人看到index condition，误以为“c也用来索引了”。其实这是索引条件下推（Index Condition Pushdown，ICP）机制，它做的事情是：把c= '2024-01-01'这个判断条件传给存储引擎，让引擎在扫描b范围时顺便过滤掉不满足c条件的记录，从而减少回表次数。

ICP是个好东西，但它不等于索引定位。判断“到底用了几列做定位”，看key_len最准。上面的SQL里key_len是38，对应的是a和b两列，c没有参与。把c条件移到范围查询之前，比如改成WHERE a = 100 AND b = 'value_100' AND c > '2024-01-01'，key_len就会变成42，说明三列都用上了。

3.4 误区四：SELECT字段和索引命中没关系，以及埋伏在函数和LIKE里的坑

第四个误区是认为“只要WHERE条件满足最左前缀，索引就一定能显著加速查询”。其实SELECT后面查什么字段，同样影响最终效果。

如果查询的字段都包含在索引里，比如SELECT a, b FROM test_index WHERE a = 100，InnoDB可以直接从索引的叶子节点里拿到a和b的值，不需要再回表取完整行，Extra会显示Using index。这就是覆盖索引，是联合索引性能最好的形态。相反，如果SELECT *，即使索引定位很快，也要根据主键回表读取整行数据，遇到索引列区分度不高的场景，回表次数多起来，性能依然不会太好看。

另外，WHERE条件里对索引列使用函数或者做隐式类型转换，也会破坏最左前缀的生效条件。比如在c列上写WHERE DATE(c) = '2024-01-01'，相当于把索引列作为函数入参，优化器无法直接利用c列的有序性；再比如b是VARCHAR列，却拿数字去比较，MySQL会把列做隐式转换后比较索引同样会失效。LIKE也需要留意，'value%'这种前缀匹配还能利用索引排序，'%value'这种后缀模糊就是全表扫描，和索引一致性的道理是相通的。

4. 实战调优：联合索引到底怎么设计

4.1 联合索引列顺序的四个判断维度

理解了最左前缀原则，设计联合索引的顺序才有真正依据。没有这个基础，网上那些“把区分度高的放前面”之类的口诀，用起来很容易出问题。

我一般按照下面四个维度综合判断，按优先级从高到低排：

• 等值条件优先：经常以等值条件出现且业务上必带的列，尽量放前面。因为这个列会被绝大多数查询带上，让更多SQL可以走到索引。
• 范围条件靠后：范围查询（>、<、BETWEEN）会截断后续列的定位能力，所以范围列一定要放在所有等值列之后。
• 高频查询优先：如果绝大多数查询都会带user_id，那user_id应该成为联合索引的第一列，哪怕它的区分度不是最高的。
• 区分度作为参考：如果两列都是等值条件，区分度高的放前面通常更好，因为能在B+树里更快收敛。

举个反例。有一张订单表，常见查询是WHERE shop_id = ? AND status = ?，你为了“区分度更高”，把status放前面。结果status的取值只有三五种，区分度远不如shop_id，MySQL扫描时反而要过滤更多记录。更关键的是，如果还有一条SQL是WHERE shop_id = ? GROUP BY date，你没把shop_id放前面，这条SQL可能根本走不了索引。

4.2 一个真实场景：订单列表页的索引改造

前面那个同事的案子，我把它简化成订单表的实际场景。业务上有三个典型查询：

sql复制-- 查询某个用户最近的订单
SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 10;

-- 查询某个用户某个状态下的订单
SELECT * FROM orders WHERE user_id = ? AND status = ? ORDER BY created_at DESC;

-- 运营侧查询某个状态某段时间的订单量
SELECT COUNT(*) FROM orders WHERE status = ? AND created_at BETWEEN ? AND ?;

最初的索引是独立建的，user_id一个索引，status一个索引，created_at一个索引，结果每条SQL最多只能用一个索引，排序还经常触发filesort。

改造之后：

• 针对前两条：建(user_id, status, created_at)联合索引。第一条SQL只有user_id，也能命中最左前缀，created_at利用索引有序性直接按顺序取10条，避免filesort；第二条SQL走到user_id和status两层，created_at继续负责排序，非常完美。
• 针对第三条：光靠上面的索引不够，因为查询条件里没有user_id，最左列缺失，索引直接失效。所以我单独为运营场景建了(status, created_at)索引。

这个案例最核心的收获是：不要用“每个条件单独建一个索引”的惯性思维，先看查询条件里哪些列是“必带”的，把最常组合出现的列放到同一个联合索引里，让一条SQL能吃满整个索引链路。

4.3 索引不是越多越好

每当聊到索引设计，总有人走向另一个极端：建了一堆联合索引，表里索引比字段还多。这其实是最左前缀原则带来的一个副作用——一个三列联合索引能覆盖很多查询，于是开始无脑加列。

但索引是有成本的。每次INSERT、UPDATE、DELETE都要同步维护所有索引，索引多了写入自然变慢，占用空间也成倍涨。更麻烦的是，两个有公共前缀的索引往往互相冗余。比如已经有了(a, b, c)联合索引，再单独建一个a索引就是纯浪费，因为查询条件里带a的SQL已经能复用(a, b, c)的最左前缀了。

我个人的习惯是：设计索引前，先把业务里的核心查询列出来，按“必带条件”分组，能用一两个联合索引覆盖的，绝不用三四个，尤其要避免建立重复前缀的冗余索引。真到了线上，索引不是越多越好，而是越“精准”越好。

5. 日常排查和避坑清单

5.1 三条自查规则

我现在排查“索引没生效”类问题，基本是不看执行计划的，先问自己三个问题，就能定位大半问题。

第一，查询条件里有没有包含联合索引的最左列？没有，基本可以判断当前SQL没走这个索引，或者只能全表扫描。第二，条件里的列是不是从最左列开始“连续的”前缀？中途断了一列，后面的列再齐全也没用。第三，最靠前的范围查询列后面，还有没有别的等值条件？有的话，那些等值条件不会参与索引定位，需要评估回表之后的数据量。

这三条规则听着朴素，但每条背后都是B+树存储结构推导出来的。把这三条刻在脑子里，比背多少篇文章都管用。

5.2 常见场景速查表

下面这张表是我自己整理的常见场景速查，直接对着看就行。

最后再加一条：WHERE a IN (1, 2, 3) AND b = 5这种，在MySQL里通常可以继续用b定位，因为IN列表本质上被展开成多个等值条件，不会像范围比较符号那样“截断”后边的列。但具体版本和优化器策略有差异，线上还是以EXPLAIN为准。

5.3 一点个人经验

这些年处理过的慢查询，十有七八都能归到最左前缀原则没理解透上。每次看到有人把问题归结为“MySQL索引不灵”，我都会拉一条EXPLAIN出来，指着他SQL里的条件顺序说：“你这不是没建索引，是没让索引有机会发挥它的结构优势。”

如果非要说一个最能提升效率的习惯，那就是看EXPLAIN的时候永远把key_len和Extra一起看。key_len告诉你索引实际用了多少列，Extra告诉你有没有回表、有没有额外过滤。两个字段结合起来，比只盯着type是不是ref可靠得多。

另外，做线上索引变更前，尽量在预发布环境用真实数据量验证一下。小数据量下全表扫描也就几毫秒，看不出差距；一旦上了千万级数据，索引命中与否可能就是毫秒和秒级的区别。最左前缀原则不是背完就结束的知识点，它是你写SQL和设计索引时脑子里一直在转的那根弦。