mysql执行SQL过程中会发生回表吗_索引执行流程说明_网络技术

MySQL在InnoDB中使用二级索引查询时，若SELECT字段未被索引完全覆盖，需回表到聚簇索引获取完整行数据；典型场景包括SELECT含非索引列、ORDER BY/GROUP BY涉及非索引列等，可通过EXPLAIN的Extra字段判断，如无“Using index”即可能回表。

会，只要 SELECT 的字段不在当前使用的索引中全部覆盖，且引擎是 InnoDB，就大概率发生回表。回表不是语法行为，而是 InnoDB 在二级索引（非聚簇索引）查到主键后，再拿着主键去聚簇索引（即主键索引）里捞完整行数据的过程。

典型触发场景：WHERE 条件走了二级索引，但 SELECT 里包含了该索引没包含的列（比如 SELECT name, email FROM users WHERE city = 'Beijing'，而 city 是单独的二级索引）。

看 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)：

注意：ORDER BY city, name 可利用该索引避免文件排序；但 ORDER BY name 单独出现，无法利用，可能触发回表+临时表+filesort。

一次回表 ≈ 一次随机主键查找（B+ 树搜索），在 SSD 上约 0.1–0.3ms，在 HDD 上可能达几毫秒。当扫描 10 万行二级索引记录，就要额外做 10 万次主键查找 —— IO 放大严重，极易成为瓶颈。

真正容易被忽略的是：开发常以为「有索引=快」，却没检查 EXPLAIN 的 Extra 列，也没验证 SELECT 列是否被索引完全覆盖——回表往往静默发生，直到慢查询日志爆发才被发现。