如果你已经在使用索引，查询却依然很慢，很可能你正遭遇 “回表” 带来的隐形性能损耗。今天这篇文章，我们来把回表这个概念，从原理到优化手段，讲得清清楚楚。

一、用一个故事理解什么是回表

想象一座巨大的图书馆：

  • 一楼是按书名拼音排序的索引卡片柜。每张卡片上只有“书名 + 书所在的书架号”。

  • 二楼是按照书架号顺序排列的实体书架，书架上才是完整的书。

现在你想找《时间简史》这本书里的全部内容。

  1. 你直奔一楼的卡片柜，按拼音找到“时间简史”的卡片，上面写着：3楼 - A区 - 12排。

  2. 你攥着这个地址，噔噔噔跑到二楼，找到3楼A区12排，终于拿到了那本完整的书。

这个跑去二楼拿完整书的过程，在 MySQL 里就叫“回表”。

  • 一楼卡片柜 = MySQL 的二级索引（只存索引列 + 主键值/页码）

  • 二楼实体书架 = MySQL 的聚簇索引（存整行数据）

  • 卡片上的地址 = 主键值

如果只是为了查“时间简史的出版年份”，而这个信息恰好直接印在卡片上了，那你根本不用上二楼。这就是覆盖索引——避免了回表。

二、结合 InnoDB 结构，看回表如何发生

InnoDB 中，数据按B+树组织。

  • 聚簇索引的叶子节点：直接挂着完整的一行记录。

  • 二级索引的叶子节点：只有索引列 + 对应的主键值。

假设有一张表：

CREATE TABLE user (
  id INT PRIMARY KEY,
  name VARCHAR(50),
  age INT,
  KEY idx_name (name)
);

查询：

SELECT * FROM user WHERE name = 'Alice';

执行过程：

  1. 遍历 idx_name 树，定位到 'Alice'，从叶子节点获取到主键，比如 id=100。

  2. 发生回表：拿 id=100 再次遍历主键聚簇索引树，在叶子节点找到 (100, 'Alice', 25) 这整行，返回。

SELECT * 需要所有列，而 idx_name 里没有 age，所以必须回表。

三、为什么回表会成为性能杀手？

如果二级索引只查出1条数据，回表1次，代价几乎可忽略。但现实往往是：

SELECT * FROM user WHERE name LIKE 'A%';

若这个查询命中了10万行，就会回表10万次。

核心原因是：随机 I/O 被放大

  • 二级索引 idx_name 中，name 按字母顺序排列，但对应的主键 id 往往是随机离散的。

  • 拿着这10万个离散的 id 去聚簇索引里逐行查找，相当于在磁盘上随机跳跃10万次。

  • 这种高强度的随机读，速度远低于顺序读，是机械硬盘和 SSD 都无法轻松承受的。

极端情况下，MySQL 优化器计算后发现回表的代价高于直接全表扫描，会放弃你精心设计的索引，选择全表扫描。 这也是为什么有时 EXPLAIN 里 type 竟然是 ALL 的原因。

四、如何用 EXPLAIN 发现回表？

执行计划中可以捕捉回表的蛛丝马迹。

假设我们用：

EXPLAIN SELECT * FROM user WHERE name = 'Alice';

重点观察 Extra 列：

  • 如果出现 Using index：好消息，索引覆盖了查询，没有回表，数据直接从索引获取。

  • 如果没有 Using index，而是 NULL 或 Using where：说明存储引擎从索引拿到主键后，又去聚簇索引取了整行数据，发生了回表。

注意：Using index condition 表示使用了索引条件下推（ICP），虽然也用到了索引，但依然有回表，只是回表前提前过滤掉了一部分行。

五、根治回表：覆盖索引

让查询所需的所有列都包含在二级索引中，就能彻底消灭回表。

对上面查询：

SELECT id, name FROM user WHERE name = 'Alice';

如果只有 INDEX(name)，叶子节点存的是 (name, id)，恰好覆盖了 id 和 name 两列，这时 Extra 就会显示 Using index，不再回表。

更复杂的查询：

SELECT name, age FROM user WHERE name = 'Alice';

可以建复合索引 INDEX(name, age)，这样叶子节点包含 (name, age, id)，依然覆盖查询，不漏 age。

覆盖索引是消除回表最彻底、最推荐的方式。

六、减轻回表之痛：索引条件下推（ICP）

当无法建覆盖索引时，MySQL 5.6+ 的 索引条件下推 (Index Condition Pushdown) 可有效减少回表次数。

索引 INDEX(name, age)，查询：

SELECT * FROM user WHERE name LIKE 'A%' AND age = 18;

  • name LIKE 'A%' 是范围条件，age 无法用于索引定位。

  • 没有 ICP 时：扫描二级索引找到所有 name LIKE 'A%' 的记录，全部回表，再从完整行里筛选 age=18。

  • 有 ICP 时：在扫描二级索引的叶子节点时，虽然不能直接跳，但存储引擎会先检查 age=18 这个条件，因为 age 就在索引里！不满足的直接丢弃不回表，只有满足的才回表。

这相当于在“翻卡片柜”时就多过滤了一道，大大减少了“跑二楼”的次数。

七、总结：回表优化三步走

  1. 先看是否必须回表：用 EXPLAIN 检查 SQL，若 Extra 无 Using index，则大概率存在回表。

  2. 优先构建覆盖索引：分析 SELECT 列和 WHERE 条件，设计复合索引，将查询所需列一网打尽，彻底避免回表。

  3. 无法覆盖则利用 ICP 减压：确保索引包含足够多的条件列，让 ICP 在索引层提前过滤，减少回表行数。

理解回表，是你从会用索引到精通索引优化的分水岭。下次遇到 SQL 优化，不妨先问问自己：这个查询，回表了吗？