回表是innodb二级索引结构决定的必然行为，因二级索引叶子节点仅存索引列值和主键id，不存name等非索引字段，故查select name需先通过二级索引获取id，再回聚簇索引取完整行；explain中type为ref/range且extra无using index即表明发生回表；优化核心是覆盖索引或调整sql只查索引包含字段。
回表不是bug，是InnoDB二级索引的物理结构决定的
MySQL（InnoDB）执行 SELECT name FROM user WHERE city = '北京' 时发生回表，根本原因不在SQL写法或优化器逻辑，而在二级索引叶子节点里**本来就不存 name 字段**。它只存两样东西：city 值 + 对应行的主键 id。引擎查完索引拿到一批 id，必须再拿这些 id 去聚簇索引（也就是主键索引）里逐个捞整行——这个“再跑一趟”的动作就是回表。
这不是设计缺陷，而是空间换时间的权衡：二级索引体积小、树矮、定位主键快；但代价就是不能直接返回非索引列。
- 聚簇索引叶子节点：存完整行数据（
id,name,age,city…） - 二级索引叶子节点：只存索引列 + 主键（如
city和id），不存name、age等其他字段 - 只要
SELECT列表里有任何一个字段没出现在当前使用的二级索引中，就必然触发回表
EXPLAIN 中怎么一眼识别回表？看 Extra 和 type
运行 EXPLAIN SELECT name FROM user WHERE city = '北京'，重点关注两列：
-
type是ref或range（说明用了二级索引） -
Extra字段为空，或出现Using index condition，但**没有Using index**
一旦 Extra 出现 Using index，说明命中了覆盖索引——所有要查的字段都在索引里，不用回表。比如 SELECT city, id FROM user WHERE city = '北京' 就可能走 idx_city 并显示 Using index。
注意：Using index condition 是索引下推（ICP），它只是把部分 WHERE 过滤提前到存储引擎层做，**不改变回表本质**——只要最终要取的字段不在索引里，ICP 后仍需回表。
避免回表最直接有效的两种方式
核心思路就一个：让查询所需的所有字段，全部落在同一棵二级索引树的叶子节点上。
- 建联合索引，把
WHERE条件列 +SELECT列一起包含进去。例如：ALTER TABLE user ADD INDEX idx_city_name (city, name)，之后SELECT name FROM user WHERE city = '北京'就不再回表 - 改写 SQL，只查索引已有的字段。例如原语句是
SELECT * FROM user WHERE city = '北京'，若只需id和name，且已有idx_city_id_name（含city,id,name），就显式写成SELECT id, name FROM user WHERE city = '北京' - 不要迷信“加索引就能加速”，如果联合索引顺序错（比如建了
(name, city)却查WHERE city = ?），连索引都用不上，更别说避免回表
回表性能差的真正瓶颈是随机IO，不是“多查一次”
很多人以为回表慢是因为“多走了一次B+树查找”，其实关键在磁盘访问模式。假设 idx_city 返回 1000 个 id，而这些 id 在主键索引中物理位置高度离散（比如因自增中断、大量删除插入导致主键不连续），那么这 1000 次回表就会触发 1000 次随机磁盘 IO——这才是高并发下响应陡升、QPS骤降的根源。
相比之下，覆盖索引或主键查询是顺序或局部聚集读，IO 效率高得多。
所以优化回表，不只是“加个字段进索引”，更要关注主键设计是否利于局部性（如尽量用自增 id）、以及联合索引是否真的能减少回表行数（比如加 ORDER BY 字段进索引可避免 filesort，间接减少回表压力）。
