回表是mysql通过二级索引查到主键后，再回聚簇索引查找整行数据的过程，因随机i/o导致性能下降；可通过覆盖索引（含所有查询字段的联合索引）避免。
什么是回表，为什么它会影响查询性能
回表是指 MySQL 在使用二级索引（非聚簇索引）查到主键值后，再根据主键回到聚簇索引（即主键索引的 B+ 树）中查找完整行数据的过程。每次回表都是一次随机 I/O，尤其在数据量大、内存不足时，性能损耗明显。
常见触发回表的场景包括：
-
SELECT *查询配合二级索引 -
SELECT中包含未被索引覆盖的字段 -
WHERE条件用了二级索引，但ORDER BY或GROUP BY需要额外字段
回表不是语法错误，而是执行计划里隐含的代价——Extra 列出现 Using index condition; Using where 通常没问题，但若出现 Using where; Using index; Using filesort 或没 Using index，就大概率在回表。
用覆盖索引避免回表：只查索引里有的字段
覆盖索引（Covering Index）是解决回表最直接的方式：让查询所需的所有字段都包含在同一个二级索引中，这样 MySQL 直接从索引叶节点取数，无需回主键树。
实操要点：
- 把
WHERE条件字段放最前（符合最左前缀） - 把
SELECT中所有字段都加进索引列尾部（顺序不关键，但要全包含） -
ORDER BY字段若需避免排序，也建议加入索引（且顺序一致）
例如表 t_user 有 (id, name, age, city)，常查 SELECT name, age FROM t_user WHERE city = 'Beijing'，建索引应为：
ALTER TABLE t_user ADD INDEX idx_city_name_age (city, name, age);而不是只建
INDEX(city) —— 后者会导致回表取 name 和 age。
注意：索引列越多、越宽，写入开销和内存占用越大，别无脑堆字段。
联合索引顺序怎么排：WHERE、ORDER BY、SELECT 的优先级
联合索引字段顺序直接影响能否命中覆盖索引，也决定是否需要回表或排序。
判断顺序的依据是执行路径：
- 第一层：所有
WHERE等值条件字段（按任意顺序，但必须连续出现在索引开头） - 第二层：单个
ORDER BY字段（如果是范围查询如city > 'A'，后续字段无法用于排序或覆盖） - 第三层：剩余
SELECT字段（补全覆盖需求）
错误示例：
SELECT name, age FROM t_user WHERE city = 'Beijing' ORDER BY age;如果建索引为
(city, age, name)，能覆盖；但如果建为 (city, name, age)，虽然也能查，但 ORDER BY age 无法利用索引，会触发 Using filesort，还可能间接导致优化器放弃覆盖路径。
另一个坑：IN 和 OR 条件会让等值判断失效，比如 WHERE city IN ('A','B') AND name = 'Tom'，此时 city 实际是范围扫描，name 后面的字段大概率无法用于覆盖。
用 EXPLAIN 验证是否真的避免了回表
光看 SQL 写得“好像”能覆盖不行，必须用 EXPLAIN FORMAT=TREE（MySQL 8.0+）或传统 EXPLAIN 观察执行细节。
关键看三处：
-
type是ref或range（说明走了索引） -
key显示实际使用的索引名 -
Extra中出现Using index（表示覆盖索引生效），没有Using where单独出现（否则说明还在回表后过滤）
特别注意：如果 Extra 是 Using index condition，说明用了 ICP（Index Condition Pushdown），这是好现象，但不等于覆盖——它只是把部分 WHERE 下推到存储引擎层过滤，仍可能回表取其他字段。
复杂点在于：即使你建了覆盖索引，MySQL 优化器也可能因统计信息不准、临时表、隐式类型转换等原因弃用它。所以每次改索引后，务必用真实数据量 EXPLAIN 验证，别只在测试库跑几条 SELECT 就认为 OK。
