回表慢是因为需两次B+树查找：先用二级索引查主键，再以主键回聚簇索引取整行，引发大量随机I/O和缓存失效；EXPLAIN中Extra无Using index即表明回表。
为什么回表会拖慢查询
回表的本质是：用二级索引查到主键值后，再拿这个主键去聚簇索引（也就是主键索引）里捞整行数据。InnoDB 的二级索引叶子节点只存索引列 + 主键值，不存其他字段——所以只要 SELECT 的字段不在该索引里，就必须多一次 B+ 树查找，带来随机磁盘 I/O。100 万行数据里若要回表 5 万次，就等于额外读取 5 万个数据页，缓存命中率骤降，QPS 直接腰斩。
如何判断当前查询是否走覆盖索引
执行 EXPLAIN 查看 Extra 列：
- 出现
Using index→ 覆盖索引生效，全程只扫一棵索引树 - 出现
Using where; Using index→ 索引下推（ICP）也参与了过滤，但仍是覆盖索引 - 只有
Using where或空 → 没有覆盖，必然回表
注意：SELECT * 几乎永远无法触发 Using index，因为二级索引不含所有字段；哪怕表只有 3 列，只要没把它们全建进同一个索引，就回表。
怎么设计能真正覆盖的联合索引
核心原则：把 WHERE 条件字段 + SELECT 字段一起放进一个联合索引，且顺序要合理：
-
WHERE中的等值条件放最左（如user_id = ?） - 范围条件（
>、BETWEEN）放中间，它右边的字段无法走索引 -
SELECT字段补在最后（如只需要status和created_at，就加在索引末尾） - 主键自动包含在二级索引中，所以
SELECT id不额外占空间，但显式写上更清晰
示例：查询 SELECT id, status FROM order WHERE user_id = 123 AND created_at > '2025-01-01'，建索引应为 INDEX idx_user_time_status (user_id, created_at, status) —— 这样 id 自带，status 显式覆盖，避免回表。
容易被忽略的坑和边界情况
覆盖索引不是万能的，几个典型陷阱：
- 使用
ORDER BY时，如果排序字段不在索引中或顺序不匹配，即使 SELECT 字段全覆盖，也可能被迫回表做文件排序（Using filesort） -
TEXT、BLOB类型字段无法被索引存储，哪怕写进联合索引，MySQL 也会静默忽略，导致实际未覆盖 - 索引总长度不能超过 3072 字节（InnoDB 默认），过长的
VARCHAR字段要指定前缀长度，否则建索引失败 -
NULL值处理：如果WHERE条件含IS NULL，而索引列允许NULL，需确认优化器是否仍走索引（可用EXPLAIN验证）
最常被低估的一点：覆盖索引对 COUNT(*) 和分页（LIMIT offset, size）提升极大，但前提是 WHERE 条件能命中索引，且不带 SELECT * —— 否则优化器宁可全表扫描也不愿回表上万次。
