回表查询是innodb二级索引查到主键后再回聚簇索引取数据的过程，因随机i/o和额外b+树遍历导致性能下降；优化手段包括覆盖索引、索引下推（icp）和多范围读（mrr）。
回表查询是 MySQL InnoDB 引擎中一个常见但容易被低估的性能瓶颈。它本质不是 bug，而是二级索引设计带来的必然行为：用空间换查询速度时，牺牲了字段覆盖能力。真正影响性能的，是回表引发的随机 I/O 和额外 B+ 树遍历开销。
回表是怎么发生的？
核心在于 InnoDB 的两类索引结构差异：
- 聚簇索引（主键索引）：叶子节点存整行数据，数据物理顺序和主键一致；每张表只有一个。
- 二级索引（如普通索引、联合索引）：叶子节点只存“索引列值 + 对应主键值”，不存其他字段。
当你执行 SELECT name FROM user WHERE city = '杭州'，而只有 INDEX idx_city(city) 时，MySQL 先在二级索引中找到所有匹配的主键 ID，再逐个拿这些 ID 去聚簇索引里查 name——这个“拿 ID 再查一次”的动作，就是回表。
执行计划中若出现 type = ref/ range 但 Extra 列为 null（而非 Using index），就说明发生了回表。
为什么回表慢？关键在随机 I/O
二级索引按 city 排序，但查出来的主键 ID 往往是乱序的（比如 107、3、892、45）。回表时就要按这个顺序去磁盘加载不同页——每次加载都可能是一次随机 I/O。
- 顺序 I/O 平均耗时约 0.1ms/页
- 随机 I/O 平均耗时约 10ms/页（相差百倍）
查 1000 行，若每个主键落在不同页上，光 I/O 就可能拖慢数秒。更糟的是，大量回表会挤占 Buffer Pool，降低整体缓存命中率。
三类实用优化手段
1. 覆盖索引（最直接有效）
让查询所需字段全部落在同一个二级索引中，彻底避免回表。
- 例如原查询
SELECT id, name, city FROM user WHERE city = '北京' AND age > 25，可建联合索引：ALTER TABLE user ADD INDEX idx_city_age_name (city, age, name) - 注意字段顺序：等值条件放前（
city），范围条件居中（age），要查的非条件字段放后（name）
2. 索引下推（ICP，MySQL 5.6+ 默认开启）
把部分 WHERE 条件“下推”到二级索引扫描阶段，在回表前就过滤掉无效记录。
- 有索引
(age, city)时，WHERE age > 20 AND city = '上海'可在索引层直接判断city，不必为每个age > 20的记录都回表 - 执行计划中出现
Using index condition即表示生效
3. 多范围读（MRR，需配合优化器开关）
对一批待回表的主键值先排序，把随机 I/O 转为顺序 I/O。
- 开启方式：
SET optimizer_switch='mrr=on,mrr_cost_based=off'; - 效果体现：执行计划中出现
Using MRR，且read_rnd_buffer_size缓冲区大小会影响排序效率 - 适合批量查询（如
IN列表或范围扫描返回数百行以上）
哪些情况其实不该依赖二级索引？
不是所有带索引的查询都更快。当回表成本过高时，优化器可能主动放弃二级索引，改走全表扫描（即聚簇索引扫描）。
- 典型信号：明明有索引，
EXPLAIN却显示type = ALL或rows预估远超实际返回行数 - 常见诱因：查询条件选择率高（如
WHERE status != 0）、索引区分度低（如性别字段）、或返回大量字段 - 对策：优先考虑覆盖索引，或评估是否真需要查那么多字段（
SELECT *是回表大户）
