回表是指MySQL通过二级索引查到主键后，再回聚簇索引查找整行数据的过程，因随机I/O导致查询变慢；覆盖索引可避免回表，即查询字段全部包含在同一个索引中且EXPLAIN显示“Using index”。
什么是回表，为什么它会让查询变慢
MySQL 的 SELECT * 或非索引字段查询，在使用二级索引（比如普通 INDEX）时，会先查索引树拿到主键值，再拿主键去聚簇索引（主键索引）里捞整行数据——这个“回到主键索引再查一次”的过程就叫回表。它本质是随机 I/O，比顺序扫描索引还贵，尤其在大表、高并发下，延迟和 CPU 消耗明显升高。
常见错误现象：EXPLAIN 结果中 type 是 ref 或 range，但 Extra 列出现 Using index condition; Using where 甚至没写 Using index，基本说明没走覆盖索引，大概率要回表。
怎么用覆盖索引避免回表
覆盖索引 = 查询所需的所有字段，全部包含在同一个索引的列中（顺序不重要，但必须全有）。只要满足这个条件，MySQL 就能直接从索引 B+ 树叶子节点拿到全部数据，不用回主键索引。
实操建议：
- 把
WHERE条件字段放前面（用于快速定位），SELECT中的其他字段追加在后面，比如查询SELECT name, age FROM user WHERE city = 'Beijing'，建索引应为INDEX(city, name, age)，而不是只建INDEX(city) - 避免在覆盖索引里包含
TEXT、BLOB类型字段——它们不存于索引叶子节点，会导致索引失效 - 联合索引字段数别贪多，超过 5 个字段的索引维护成本高、写入变慢，且容易因
WHERE条件未用最左前缀而无法命中 - 注意
ORDER BY和GROUP BY字段如果也在 SELECT 里，也得放进索引，否则可能触发 filesort，抵消覆盖收益
EXPLAIN 看懂是否真覆盖了
EXPLAIN 的 Extra 列出现 Using index 是唯一可靠信号，代表本次查询完全使用索引数据，没回表。只要没这四个字，哪怕用了索引，也大概率回表了。
容易踩的坑：
-
SELECT *几乎不可能被覆盖，除非你给整张表建了个含所有字段的联合索引（不现实） - 隐式类型转换会让索引失效，比如
city = 123（city 是 varchar），即使有INDEX(city)，也会导致无法走覆盖，更别说回表规避 -
LIKE '%xxx'无法用到索引前缀，整个索引失效，自然谈不上覆盖 - 使用函数操作索引字段，如
WHERE UPPER(name) = 'TOM'，同样跳过索引，回表不可避免
覆盖索引不是万能的，这些场景它帮不上忙
覆盖索引只解决“读多写少、查询字段固定”的 OLTP 场景。一旦涉及以下情况，就得换思路：
- 需要
UPDATE或DELETE某些行：覆盖索引不存储行锁信息，DML 还是要定位到聚簇索引，回表照旧 - 查询条件动态拼接、字段不固定：比如后台通用搜索接口，很难预设一个索引覆盖所有组合
- 单表数据量不大（
- 使用了
SELECT ... FOR UPDATE：InnoDB 必须加锁到聚簇索引记录上，覆盖索引无法替代
真正难的不是建对索引，而是判断哪些查询值得为它单独设计索引——字段组合、更新频率、查询频次，三者得一起看。漏掉任何一个，都可能让覆盖索引变成负担。
