回表是MySQL在二级索引查询中因返回列不全在索引内而需回主键索引查找完整行的过程；覆盖索引可避免回表，要求查询所有列均包含在同一索引叶子节点中。
回表就是“查两次索引”
当你用 WHERE age = 25 查询，而 age 上只有普通索引（比如 INDEX idx_age(age)），但 SELECT 的字段包含 name 或 city 这些没在索引里的列时，MySQL 就必须：先查二级索引拿到匹配的主键 id 列表，再拿每个 id 去主键索引里逐条找完整行——这第二次查找，就是回表。
本质不是“访问表”，而是“访问聚簇索引”。InnoDB 中，数据就存在主键索引的叶子节点里，所以回表 = 回到主键索引树查数据。
- 触发前提：查询走二级索引 + 返回列不全在该索引中
- 不触发场景：
SELECT id, age FROM user WHERE age = 25（索引含age和隐式主键id） - 典型错误现象：
EXPLAIN中Extra字段只显示Using where，没有Using index
覆盖索引 = 让回表彻底消失
覆盖索引不是一种特殊索引类型，而是指“你查的每一列，都在同一个索引的叶子节点里存着”。只要满足这点，MySQL 就能直接从索引中返回全部结果，跳过回表。
实操关键点：
- 联合索引顺序很重要：
INDEX idx_city_age_name (city, age, name)能覆盖SELECT city, age, name，但不能覆盖SELECT name, city（违反最左前缀） - 主键自动包含：所有二级索引叶子节点都带主键值，所以
SELECT id, city只要city在索引里，就一定覆盖 - 避免冗余列：别把
TEXT或超长VARCHAR加进索引——索引体积暴涨，反而拖慢查询 - 验证方式：
EXPLAIN看Extra是否出现Using index（注意不是Using index condition，后者仍需回表）
哪些情况看似能覆盖，其实还在回表？
容易被忽略的“伪覆盖”陷阱：
-
SELECT *永远无法被任何二级索引覆盖（除非你建了个包含所有字段的联合索引，但极不推荐） - 使用函数或表达式：
SELECT UPPER(name) FROM user WHERE age = 25—— 即使name在索引里，UPPER()导致无法直接取值，仍需回表取原始name再计算 -
隐式类型转换：
WHERE age = '25'（字符串）可能让优化器放弃索引，或导致索引只能用于查找、不能用于覆盖 -
ORDER BY非索引顺序：SELECT city, age FROM user WHERE city = '北京' ORDER BY name—— 即使city, age覆盖，但排序字段name不在索引里，可能触发 filesort + 回表
实战中怎么快速判断和修复？
别靠猜，用 EXPLAIN FORMAT=TREE（MySQL 8.0+）或 EXPLAIN 结合 SHOW INDEX 对照看：
- 第一步：
EXPLAIN SELECT name, city FROM user WHERE age = 25;→ 看key用了哪个索引，Extra是什么 - 第二步：
SHOW INDEX FROM user WHERE Key_name = 'idx_age';→ 确认这个索引到底包含哪些列 - 第三步：如果发现缺列，补全索引：
ALTER TABLE user DROP INDEX idx_age, ADD INDEX idx_age_covering (age, name, city); - 注意：添加覆盖索引会增加写开销和磁盘占用，高频更新的列要谨慎；优先覆盖读多写少的查询路径
真正难的不是建索引，而是意识到：回表不是慢在 SQL 写得差，而是索引没对上查询需求。一个 Using index 和一个 Using where，背后可能是 2 倍还是 10 倍的 I/O 差距。
