MySQL在InnoDB中使用二级索引查询时，若SELECT字段未被索引完全覆盖，需回表到聚簇索引获取完整行数据；典型场景包括SELECT含非索引列、ORDER BY/GROUP BY涉及非索引列等，可通过EXPLAIN的Extra字段判断，如无“Using index”即可能回表。
MySQL 什么时候会回表？
会，只要 SELECT 的字段不在当前使用的索引中全部覆盖，且引擎是 InnoDB，就大概率发生回表。回表不是语法行为，而是 InnoDB 在二级索引（非聚簇索引）查到主键后，再拿着主键去聚簇索引（即主键索引）里捞完整行数据的过程。
典型触发场景：WHERE 条件走了二级索引，但 SELECT 里包含了该索引没包含的列（比如 SELECT name, email FROM users WHERE city = 'Beijing'，而 city 是单独的二级索引）。
- 只有
SELECT *或含非索引列时才可能回表；如果SELECT的全是索引列（包括联合索引中的部分或全部），就走“索引覆盖”，不回表 -
ORDER BY或GROUP BY涉及非索引列，也可能迫使回表（即使WHERE匹配了索引） - 使用
LIKE 'xxx%'走了索引，但选了非索引列 → 同样回表
如何判断一条 SQL 是否回表？
看 EXPLAIN 输出里的 Extra 字段：
- 出现
Using index：说明走了索引覆盖，没回表 - 出现
Using where; Using index：也属于索引覆盖（WHERE在索引上完成，无需回表取数据） - 只出现
Using where（没带Using index）：大概率回表了 - 出现
Using index condition：用了 ICP（索引下推），仍可能回表——ICP 只是把部分WHERE过滤下推到存储引擎层，不代表不取整行
EXPLAIN SELECT id, name FROM users WHERE city = 'Shanghai';
若 city 是普通索引，而 name 不在该索引中，则 Extra 里不会出现 Using index，实际执行时就会回表。
联合索引怎么影响回表？
联合索引的顺序和 SELECT 列是否被“覆盖”，直接决定回表与否。例如建立索引 INDEX idx_city_name_age (city, name, age)：
-
SELECT city, name FROM ... WHERE city = 'X'→Using index，不回表 -
SELECT city, name, age FROM ... WHERE city = 'X'→ 仍不回表（全在索引里） -
SELECT city, name, email FROM ... WHERE city = 'X'→ 回表（email不在索引中） -
SELECT name FROM ... WHERE age = 25→ 无法用该联合索引（最左前缀不匹配），可能走全表或其它索引，与回表无关
注意：ORDER BY city, name 可利用该索引避免文件排序；但 ORDER BY name 单独出现，无法利用，可能触发回表+临时表+filesort。
回表对性能的影响有多大？
一次回表 ≈ 一次随机主键查找（B+ 树搜索），在 SSD 上约 0.1–0.3ms，在 HDD 上可能达几毫秒。当扫描 10 万行二级索引记录，就要额外做 10 万次主键查找 —— IO 放大严重，极易成为瓶颈。
- 回表不可缓存：每次都要访问聚簇索引页，Buffer Pool 命中率低
- 并发高时，大量回表加剧 Buffer Pool 和磁盘争用
- 优化方向优先是“让查询走覆盖索引”，而不是盲目加索引；加宽联合索引前需评估写入开销和维护成本
-
innodb_read_ahead_threshold等参数对回表无实质缓解作用，它只影响预读，不改变回表逻辑
真正容易被忽略的是：开发常以为「有索引=快」，却没检查 EXPLAIN 的 Extra 列，也没验证 SELECT 列是否被索引完全覆盖——回表往往静默发生，直到慢查询日志爆发才被发现。
