MySQL索引不生效的底层真相：从B+树回表成本到EXPLAIN排查

常常在技术群里看到这样的提问：“我给表的字段加了索引，为什么一条查询还是跑了三秒？EXPLAIN 里明明能看到这个索引，可 key 那列就是空。”如果你也遇到过，多半是对 MySQL 索引的理解还停留在“建了就应该走”的阶段。实际上索引不是开关，它只是给优化器多提供了一条候选路径，最终走不走，全看成本。这篇文章会把索引的底层匹配规则、联合索引设计、各种失效场景的真实原因、索引下推（ICP）以及用 EXPLAIN 定位问题的完整链路串一遍，适合刚被“索引没生效”折磨过的后端开发，也适合带新人、做代码评审的资深工程师拿来当一份速查底稿。

1. 先回答一个反直觉的问题：为什么 MySQL 会“看不上”你建的索引

1.1 二级索引并不是数据的“副本”，是另一棵独立的 B+ 树

很多人以为在 InnoDB 里建了一个普通索引，就等于给表做了一份带排序的影分身，查询时 MySQL 会优先去这份影分身里找。这个理解严格说只对了一半。

InnoDB 表本身是按主键组织数据的聚簇索引，主键索引的叶子页直接存放整行数据。而二级索引（也就是我们平时手动创建的普通索引）是另一棵 B+ 树，它的叶子页只存放两样东西：索引列的值和对应行的主键值。也就是说，如果你执行的是 SELECT *，即使通过二级索引找到了目标主键，也还要拿着这些主键值回到聚簇索引里再查一遍完整行。这个过程就叫回表，一次回表至少多一次随机读页。

这里就有个很实际的问题：你建的索引越多、索引列组合越长，每一次 INSERT、UPDATE、DELETE 需要维护的 B+ 树就越多，同时读多写少的业务里最怕的随机回表也越容易出现。所以，二级索引本质不是“数据快照”，而是一个用于定位主键的“目录”，目录写得再好，也得翻回正文才能拿到完整内容。

1.2 回表成本成了优化器衡量“要不要走索引”的核心变量

MySQL 的查询优化器在做选择时，不是凭感觉判断哪个索引好，而是会把候选执行路径的成本估算出来，最后选一条它认为总代价最低的计划。总代价包含 IO 成本、CPU 成本、内存排序成本等，其中二级索引访问的 IO 成本大头几乎都落在回表上。

举个直观的例子。一张用户表有 100 万行，你在 status 字段上建了单列索引，某天执行：

sql复制SELECT * FROM users WHERE status = 1;

假设表中 status = 1 的数据有 60 万行。优化器一算账：如果走二级索引，需要先把 60 万个主键从索引 B+ 树里找出来，再回表 60 万次；如果直接全表扫描聚簇索引，虽然要读很多数据页，但顺序读的成本通常比大量离散回表低得多。结果就是，哪怕 EXPLAIN 的 possible_keys 里能看到你建的索引，实际 key 列也可能给出 NULL，表示“这条路我评估过了，不划算”。

明白了这个前提，你才能理解后面所有的失效场景。索引失效不是一个魔法现象，它只是“当前条件无法让二级索引高效定位并低成本回表”时才出现的必然结果。

1.3 覆盖索引让“叶子页就是终点”，绕过回表这个成本大头

既然回表这么贵，那有没有办法让二级索引一查到底？有，这就是覆盖索引。如果一个查询需要的所有列都包含在同一个二级索引里，InnoDB 就不用再回聚簇索引取整行，直接从二级索引的叶子页拿数据返回就行。

例如：

sql复制CREATE INDEX idx_user_status ON users(status, name);
SELECT name FROM users WHERE status = 1;

这个查询里 status 用来定位，name 在索引里直接就有，不需要回表。EXPLAIN 的 Extra 列会出现 Using index，意思就是当前查询被索引覆盖了。

我通常的建议是：对于高频且固定的查询，优先考虑建覆盖索引，而不是去纠结“为什么这个索引明明能用却没走”。因为一旦查询不需要回表，优化器对索引的偏见就会小很多，执行计划也会稳定得多。

2. 联合索引的字段顺序，决定了半个索引会不会白建

2.1 一个订单系统里最常见的查询集合

先说一个我给别人做索引评审时反复用到的场景。假设你手上有一张订单表：

sql复制CREATE TABLE order_info (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    order_no VARCHAR(64) NOT NULL,
    order_status TINYINT NOT NULL,
    pay_status TINYINT NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    create_time DATETIME NOT NULL
) ENGINE=InnoDB;

业务方一开始只关心单个查询：

sql复制SELECT * FROM order_info WHERE user_id = 10001 ORDER BY create_time DESC LIMIT 20;

很自然地，开发会建 idx_user_id(user_id)，也确实能跑得不错。但业务继续扩展，又来了两个高频查询：

sql复制-- 查询某个用户某个状态下的订单
SELECT * FROM order_info WHERE user_id = 10001 AND order_status = 2;

-- 后台查询某段时间内某个状态的订单做导出
SELECT * FROM order_info WHERE order_status = 2 AND create_time BETWEEN '2025-01-01' AND '2025-01-31';

这时候头痛的问题就来了：是继续在 user_id、order_status、create_time 上各自加单列索引？还是建一个联合索引？如果建联合索引，字段顺序怎么排？

2.2 最左前缀不是背出来的规则，而是 B+ 树排序方式的必然结果

很多面试资料把“最左前缀原则”列为背诵题：联合索引 (a, b, c)，查询只有 b 时用不上，查询同时有 a 和 c 时只有 a 能用于索引检索。但为什么是这个规则，很多人没讲透。

你可以把联合索引想象成一本先按姓、再按名、最后按中间字排序的通讯录。同一个“姓”下面的人，名字才是按顺序排的；不同的姓之间，名字的字典序是完全没有意义的。如果你想快速找到所有“中间字是某某”的人，在一个必须先按姓检索的通讯录里根本没法直接定位，因为“中间字”这个维度只有在姓和名都确定后才体现顺序。

回到数据库的 B+ 树：索引 (a, b, c) 的排序规则是先按 a 排，a 相同再按 b 排，b 也相同才按 c 排。因此：

• 查询条件里只有 b = ? 时，叶子页的第一排序键完全没有约束，你无法从树根确定要进入哪个范围。
• 查询条件有 a = ? AND c = ? 时，a 能确定一个大范围，但在同一个 a 下，叶子节点按 b 排序，c 的筛选无法在跳转阶段直接使用，只能在 a 的范围内一条条判断，效果大打折扣。

这个“通讯录”模型能帮你推演出所有联合索引场景：想在一个维度上快速定位，它左侧的所有维度都必须有确定的等值条件。

2.3 等值列放前面，范围列放后面，然后按查询频率取舍

基于这个规则，设计联合索引时有一个很好用的经验顺序：

1. 把查询里出现在等值条件（=、IN）的列放在联合索引前面。
2. 把范围条件（BETWEEN、>、<、LIKE 前缀匹配）的列放在等值列之后。
3. 如果还有排序和分组需求，再看看能不能直接利用索引顺序，避免 filesort。

回到订单表。user_id = ? AND order_status = ? AND create_time BETWEEN ? AND ? 这类查询，最合理的联合索引通常是 (user_id, order_status, create_time)。这样 user_id 和 order_status 先锁定一个比较窄的叶子区间，create_time 在这个区间里又是有序的，还能顺便满足按时间范围扫描。

如果某个查询只有 order_status 和 create_time，没有 user_id，那上一个索引的 user_id 前缀就用不上。这时候需要判断这个查询是不是足够核心：如果它是后台高频导出，单独建一个 (order_status, create_time) 是合理的；如果只是偶尔跑一次，那让它扫描也不要硬加太多索引，因为索引维护成本会反噬写入性能。

这里还涉及一个长字段的问题。如果要在很长的 VARCHAR 列上建索引，比如 url，全列索引会让 B+ 树变得又宽又慢，业务上通常会用前缀索引，取前 N 个字符作为索引内容。但是要注意，前缀索引会把覆盖索引能力直接废掉，因为你索引里存的不是完整列值，无法直接返回原始数据。是否使用前缀索引，一定要结合查询列来权衡，不要一刀切。

3. 从隐式转换到 LIKE '%xxx'：那些“名字不同、机制相同”的失效现场

3.1 varchar 字段接了 int 条件：优化器悄悄给列做了一次函数运算

所有索引失效问题里，出现频率最高的一幕大概是这个：

sql复制SELECT * FROM user WHERE phone = 13800138000;

phone 字段是 varchar，但查询条件传了一个整数。MySQL 在比较不同类型的值时，会按类型转换规则把字段列或参数转成统一类型。对这条 SQL 来说，优化器往往会把字符串列转成数值再比较，相当于对 phone 执行了一次隐式的 CAST(phone AS SIGNED)。

一旦列被隐藏在函数运算里，B+ 树原本按字符串排序的有序结构就失效了，因为优化器无法基于原索引键直接做定位。解决办法很简单：传参时严格写成字符串：

sql复制SELECT * FROM user WHERE phone = '13800138000';

同样的机制也解释了为什么 find_in_set(col, '1,2,3') 这类函数本身没法走索引——MySQL 必须对 col 做函数处理才能判断它是否在集合里，这就破坏了原始索引的有序键。遇到这种需求，更可靠的办法是表结构上把多值拆成多行，或者干脆冗余一个可精确匹配的字段，而不是指望函数运算走索引。

3.2 对索引列做加减乘除：int + 5 为什么能坑人

搜索词里有一个很典型的 mysql 中 int+5。最常见写法是：

sql复制SELECT * FROM t WHERE id + 5 = 100;

这时候虽然可以数学上推导成 id = 95，但 MySQL 的优化器通常不会替你做这种列层级的代数改写。它看到的是 id + 5 这个表达式，索引键 id 被包在函数运算里，没法从根节点二分定位，于是选择全表扫描。

注意对比另一种写法：

sql复制SELECT * FROM t WHERE id = 100 - 5;

右边的 100 - 5 是常量表达式，MySQL 在优化阶段会直接算成 95，列本身没有经过任何运算，索引照常走。

这就是排查索引问题时很重要的一条判断标准：索引列是否独立出现在比较符一侧？如果列被包装了，不管是函数、隐式类型转换，还是加减乘除，优化器大概率会放弃这条索引路径。

3.3 前导模糊匹配和 find_in_set 的共性问题

LIKE 也是经典的失效现场。比如：

sql复制SELECT * FROM user WHERE nickname LIKE '%张%';

B+ 树的排序规则是按字符串从左到右排序的，你能快速定位以“张”开头的名字，因为它们在排序后的序列里是一段连续区域。但 LIKE '%张%' 要求包含“张”的所有值，这在整棵 B+ 树里可能分散在无数个不相邻的位置，根本没有“从某个起始点连续扫到某个结束点”的高效路径。所以优化器不会考虑索引定位。

同样的逻辑放在 find_in_set 上完全成立：它要求判断某个字段值是否在集合中，本质上是把字段当作数组一项项拆开再比对，无法转化为一段连续范围扫描。很多人纠结“findinset 能走索引吗”，答案是在这种用法下不能，因为你能让 B+ 树做的只是范围查找，不是集合成员判定。

3.4 OR、NOT IN、IS NULL 的真正问题在“补集”很难用树表达

先看 OR：

sql复制SELECT * FROM orders WHERE user_id = 10001 OR pay_status = 1;

假设 user_id 有索引，pay_status 没有。如果走 user_id 索引，只能拿到一部分满足条件的行，还必须再想办法找出 pay_status = 1 的所有行来合并结果，这需要另一条完整的扫描路径。多个分支如果不能同时高效执行，优化器通常会选择干脆全表扫，保证整体代价可接受。

再看 NOT IN 和“不等于”：

sql复制SELECT * FROM orders WHERE order_status NOT IN (2, 3);

B+ 树的索引组织方式天然擅长表达“从某个值到某个值”的连续区间，正着查和范围查很容易。但“不等于”或“不在集合里”是补集语义，数据的分布往往横跨整个索引序列，无法画成一段或几段紧凑的范围。优化器评估后如果发现没什么划算的区间，就会放弃索引。

IS NULL 的情况稍微特殊：NULL 值在二级索引里也会被记录，如果索引选择性允许，IS NULL 实际可以走 range 或 ref。但当你发现某条 IS NULL 查询没走索引时，多半是表里 NULL 占比太高，导致优化器认为“走索引还不如全表扫”。这些都是成本决策问题，不是一个简单的“一定走”或“一定不走”能概括的。

3.5 一张表看清这些场景的公共根因

所以排查任何一种“失效”时，先别急着背结论，而是问自己一句：这个查询条件能不能翻译成“从 B+ 树的某个位置开始连续扫到某个位置”？如果翻译不出来，索引帮不上忙是很正常的事。

4. 索引下推（ICP）：5.6 之后默认开启的索引层过滤

4.1 没有 ICP 的年代，很多“不该回表”的回表白白发生了

讲一个容易被忽略但非常实用的优化机制：索引下推（Index Condition Pushdown），英文简称 ICP。它是 MySQL 5.6 引入并默认开启的一个优化，但在很多人的知识体系里，它只是面试题里的一个名词，真正遇到时却不认识它的执行计划长什么样。

先模拟一个没有 ICP 的执行过程。假设有联合索引 (last_name, first_name)，执行：

sql复制SELECT * FROM employee 
WHERE last_name = '张' AND first_name LIKE '%三';

这里 last_name = '张' 是等值前缀，可以用到联合索引。first_name LIKE '%三' 因为前导模糊，不能进一步用来确定扫描范围。在 MySQL 5.6 之前，存储引擎会把所有 last_name = '张' 的索引项都取出来，拿到主键后立刻回表，然后把完整行返回给 Server 层，再由 Server 层判断 first_name 是否匹配。

问题很大：那些姓张但名字不是“某三”的人，一行行都被白白回表了一遍，线上很多慢查询的根源就在这里。

4.2 ICP 把过滤动作“下推”到了读索引那一刻

有了 ICP 之后，执行过程发生了变化。因为 first_name 字段本来就在联合索引 (last_name, first_name) 里，InnoDB 存储引擎在扫描二级索引的过程中，就可以边扫边判断 first_name LIKE '%三'，不满足的直接跳过，也不需要回表。这个动作相当于把原本 Server 层的过滤条件下推到了存储引擎的索引扫描层，所以叫“索引条件下推”。

你在执行计划里看到关键字 Using index condition，就说明 ICP 生效了。一个常见的误读是：看到 Using index condition 就以为查询完全不用回表。不是的，ICP 减少的是回表次数，但最终只要查询列里有索引未覆盖的字段，还是需要回表读整行。真正能完全避免回表的是 Using index，也就是覆盖索引。

4.3 什么情况下 ICP 能生效，什么情况下不能

ICP 并不是万能钥匙，它的生效有几个前置条件：

• 过滤条件里涉及的列必须包含在当前联合索引中，否则存储引擎无法在索引页上完成判断。
• 只适用于 InnoDB 和 MyISAM，像 MEMORY 表这类存储引擎不支持。
• 如果你的表是分区表，部分版本对 ICP 的支持有限制，需要确认具体版本行为。
• 查询优化器仍然会做成本判断，不是所有带 Using index condition 字样的 SQL 都比不走快，只能说多数场景下它明显减少了回表开销。

在 5.6 之前没有 ICP 的环境里，遇到“联合索引后部带无法用于定位的过滤条件”这种 SQL，想优化通常只能把过滤条件涉及的列想尽办法往前挪，或者改成覆盖索引；而在 5.6 及以上版本，ICP 给了你更大的设计余地，很多之前认为“联合索引后列用不上”的场景，现在至少能用来做索引层过滤。

一条很有用的实践经验：当你在 SQL 里发现一个字段既无法参与等值定位，又是查询必须的过滤条件时，只要这个字段出现在联合索引里，先别急着移除它，看一下 EXPLAIN 是否出现了 Using index condition。如果出现了，说明它正在帮你拦截大量回表，这个索引设计就没有白费。

5. EXPLAIN 是排查索引问题的最终标准：一次慢查询的完整体检

5.1 症状：筛选条件一堆，查询却在全表扫描

纸上谈兵再多，不如看一个真实场景。有一张百万级的订单表，开发反馈后台页面非常慢，SQL 很简单：

sql复制SELECT order_no, amount, create_time
FROM orders
WHERE order_status = 0
ORDER BY create_time DESC
LIMIT 10;

order_status 上有单列索引，create_time 上也有单列索引，可这条 SQL 实际执行了接近两秒。拿到慢查询日志后，第一步不是改 SQL，而是跑一遍 EXPLAIN：

sql复制EXPLAIN SELECT order_no, amount, create_time
FROM orders
WHERE order_status = 0
ORDER BY create_time DESC
LIMIT 10;

看到的结果是 type=ALL，possible_keys 里确实有 idx_order_status，key 却是 NULL，Extra 里还带着 Using where; Using filesort。也就是说，优化器放弃了两个单列索引，选择全表扫，最后还要额外做一次文件排序。

原因并不难猜：order_status = 0 的数据行占了全表的很大比例。优化器预估，如果走 idx_order_status，要先扫出几十万个主键，再回表判断 create_time 排序，成本远高于全表扫完再排序。既然两个单列索引单独用都很亏，谁也不会被选上。

5.2 执行计划里哪些列才是决定性的

很多人看 EXPLAIN 只看是否出现索引名，这是不够的。至少要关心五个点：

• type：访问类型。常见的从好到差依次是 system、const、eq_ref、ref、range、index、ALL。看到 ALL 就要警惕。
• possible_keys：优化器认为可能用到的索引，注意只是“可能”。
• key：优化器实际选择的索引。
• rows：优化器估算需要扫描的行数，估算得越离谱，说明统计信息越可能有问题。
• Extra：包含额外行为，比如 Using index 代表覆盖索引，Using index condition 代表索引下推，Using filesort 代表需要额外排序，这是很多排序慢查询的元凶。

连接上面的场景，正确的修法是建一个联合索引，把过滤和排序同时解决：

sql复制ALTER TABLE orders ADD INDEX idx_status_create_time (order_status, create_time);

因为最左前缀先锁定 order_status，同一 order_status 下 create_time 又天然有序，查询直接顺着索引定位到目标数据段，不需要 filesort。

5.3 possible_keys 非空就代表索引被用上？这是常见的误判

有一个特别容易误导新手的现象：EXPLAIN 结果里 possible_keys 明明写了索引名称，但 key 是 NULL，很多人就认为 MySQL 有问题。其实 possible_keys 的意思是“我看了下，这 SQL 有可能用到这些索引”，但优化器经过成本计算后认为“这些路都比全表扫描贵”，于是放弃。真正决定是否走索引的是 key 列和 type 列，不是 possible_keys。

还有一种情况是“上次走索引，这次没走”。同样的 SQL，只是换了一个查询参数，执行计划就可能完全不同。比如 order_status = 0 时因为过滤度太低走全表，但换成 order_status = 8 时，符合条件的数据很少，走索引回表的成本很低，type 又变成了 ref。

这类问题如果参数一换结果天差地别，很可能不是 SQL 的问题，而是数据分布变了，但统计信息没有及时更新。优化器是靠统计信息估算行数的，如果表的统计信息严重陈旧，它可能把一条选择性很好的查询判断成全表扫更划算。这种情况下可以执行：

sql复制ANALYZE TABLE orders;

刷新统计信息后再看 EXPLAIN，很多“莫名奇妙不走索引”的问题会直接消失。我处理线上问题时的固定顺序就是：先看慢查询日志确认 SQL，再 EXPLAIN 看基础执行计划，再用 ANALYZE TABLE 排除统计信息陈旧，最后才考虑改 SQL 或加索引。

5.4 用 optimizer_trace 看优化器的成本账本

如果以上步骤都做完了，优化器依然给了个让人无法接受的选择，不用急着骂它。MySQL 从 5.6 开始提供了优化器跟踪，能把成本计算过程全部记录下来：

sql复制SET optimizer_trace='enabled=on';
SELECT order_no, amount, create_time
FROM orders
WHERE order_status = 8
ORDER BY create_time DESC
LIMIT 10;
SELECT * FROM information_schema.OPTIMIZER_TRACE;

在输出里你会看到优化器比较了每个可用索引的访问成本、扫描行数、回表成本以及最终选择原因。有一点需要注意：优化器基于统计信息做的估算，和真实执行成本是有差距的。如果你设身处地地看一遍它的账本，能更好地理解“为什么 MySQL 没选你心里那个索引”。

5.5 一个很有用的反证手段：FORCE INDEX

当你认为优化器选错了路径，又不想大动干戈时，可以用 FORCE INDEX 做一次快速反证：

sql复制SELECT order_no, amount, create_time
FROM orders FORCE INDEX (idx_create_time)
WHERE order_status = 8
ORDER BY create_time DESC
LIMIT 10;

如果强制走某个索引后，查询反而慢得离谱，那说明优化器最初的选择是对的，问题出在索引设计不合理，而不是 MySQL 太笨。如果强制走索引后速度大幅提升，说明优化器的成本估算有偏差，此时优先检查统计信息、索引基数，再考虑是否要用更合适的联合索引。

6. 关于索引数量和优化器的边界，最后说点真实经验

6.1 索引不是越多越好，写入业务会被悄悄拖垮

我刚接触索引优化时也有过一段“见一个 WHERE 建一个索引”的时期。后来在压测环境里做一个千万级表的高频写入测试，每加一个索引，TPS 肉眼可见地往下掉，才真正意识到索引成本是实实在在的。

每次写入都会同步维护该表上的所有二级索引，数据量越大，索引树层数越深，维护成本越高。索引占用的磁盘空间和 buffer pool 内存也不是免费的。对一个每天大量插入和更新的订单类表，单表单列索引加联合索引控制在五个以内是比较稳妥的，再多就必须逐个梳理收益。

建议做一次这样的“索引审计”：从慢查询日志里把 TOP 20 慢 SQL 捞出来，逐个分析查询条件、排序字段和回表情况，然后看看是否有重复或部分重复的联合索引。例如你已经有了 (user_id, order_status, create_time)，再建一个 (user_id, order_status) 就是纯粹的浪费，前者完全覆盖后者的查询能力。

6.2 依赖个人经验不如依赖一套可复现的评审流程

实际工作中，我给自己定了一套加索引前的固定问题清单，也建议你直接抄过去用：

• 这个查询一天执行多少次？低频率的全表扫往往不值得为它加索引。
• 结果集占全表比例大概多少？低于一定阈值时走索引才划算，否则优化器会选全表扫。
• 能不能借助联合索引同时满足过滤和排序，避免 filesort？
• 查询列是否都包含在索引里，能不能顺手做成覆盖索引？
• 表当前的索引里有没有完全等价的冗余？
• 数据量涨到现在的十倍后，这个索引还有效吗？

不要凭直觉回答，每一个问题都要用 EXPLAIN 和真实数据分布来验证。

6.3 把“索引失效”当作背题，不如把它当作成本判断

回顾整篇文章，你会发现所谓的失效场景，没有一个是无缘无故的 Bug。它们背后都指向同一个核心：B+ 树只能高效处理“可以排序、可以连续定位”的检索条件；一旦条件破坏了原始键的有序性、变成了范围过大的低选择性查询、需要大量回表或无法表达成连续区间，优化器就会选择成本更低的路径。

如果你正在做面试准备，可以少背几条“失效场景”，多从 B+ 树的有序性和回表成本去推理；如果你正在排查线上慢查询，请先把 EXPLAIN 的每一列都看明白，再用统计信息更新和成本分析去验证。把这两个能力练好之后，你会发现 MySQL 的索引其实是一个很讲道理的组件，它做的每个决策都有迹可循。优化索引的最终目的，不是让 EXPLAIN 里出现一个好看的索引名，而是让每条查询在数据分布不断变化时，依旧能用最低的成本拿到需要的数据。