回表是MySQL用二级索引查到主键后，再回聚簇索引取整行数据的过程，因每次都是随机I/O而严重拖慢性能；典型场景是SELECT *或查询字段未被索引覆盖时触发。
什么是回表，为什么它影响性能
回表是指 MySQL 在使用二级索引（非聚簇索引）查到主键值后，再根据主键回到聚簇索引（通常是主键索引）中查找完整行数据的过程。每次回表都是一次随机 I/O，代价远高于顺序读取索引本身。
典型触发场景：SELECT * 或 SELECT name, age 查询中，name 有索引但 age 没有，且查询条件走的是 name 索引 —— 这时 MySQL 先用索引定位主键，再回表取 age，哪怕只多取一个字段，也可能让执行计划从“索引覆盖”退化为“回表”。
用覆盖索引彻底避免回表
覆盖索引指查询所需的所有字段都包含在同一个索引的 KEY 中，无需回表即可返回结果。这是减少回表最直接有效的方式。
- 检查执行计划：运行
EXPLAIN SELECT ...，确认Extra列是否含Using index（表示用了覆盖索引），而非Using index condition或空值（后者大概率回表） - 创建联合索引时，把
WHERE条件字段放前面，SELECT中要查的字段放后面。例如：CREATE INDEX idx_name_age ON user(name, age)可覆盖SELECT age FROM user WHERE name = 'Alice' - 注意字段顺序：
SELECT name, age能用(name, age)索引覆盖，但不能用(age, name)—— 因为索引最左前缀原则要求查询条件必须匹配索引开头字段
用主键代替 SELECT * 减少无效回表
很多业务代码习惯写 SELECT *，但实际只用其中几个字段。这会强制 MySQL 加载整行数据（即使其他字段根本不用），放大回表开销。
- 明确列出需要的字段，尤其避免在高并发或大数据量分页场景下用
SELECT * - 如果只需要主键做后续关联或跳转（如分页游标、前端渲染 ID），直接查主键即可：
SELECT id FROM user WHERE status = 1，配合应用层再按需查详情 - 对宽表（字段 >20 列）尤其敏感：回表一次可能读取 2KB+ 数据，而只查 2–3 个字段时，覆盖索引可能把单次 I/O 压缩到几十字节
联合索引字段数不是越多越好
虽然加字段能扩大覆盖范围，但索引本身变大，会导致 B+ 树层级加深、缓存命中率下降，甚至拖慢写入和范围查询性能。
实践中建议：
- 单个联合索引不超过 4–5 个字段，优先保障高频查询的覆盖性
- 避免在索引中包含
TEXT、BLOB或长VARCHAR字段（MySQL 不允许索引长度超 3072 字节，且长字段显著增大索引体积） - 用
SHOW INDEX FROM table_name查看索引大小，对比data_length和index_length，若索引总大小接近或超过数据大小，就该审视冗余索引了
回表是否发生，不取决于你写了什么 SQL，而取决于优化器选了哪个索引、以及那个索引里有没有你要的所有列。最常被忽略的一点是：明明建了索引，却因 SELECT 列没对齐索引定义，白白多出几万次随机磁盘访问。
