覆盖索引能跳过回表，因为二级索引叶子节点已包含查询所需全部字段（SELECT、WHERE、ORDER BY等），无需通过主键回聚簇索引取数据；EXPLAIN中出现“Using index”即表示生效。
覆盖索引为什么能跳过回表
因为二级索引的叶子节点里本来就存着索引列的值，只要查询所需的全部字段（SELECT 列、WHERE 条件列、ORDER BY 列、GROUP BY 列）都落在同一个索引中，MySQL 就可以直接从这棵 B+ 树的叶子节点里把数据全读出来，根本用不到主键去查聚簇索引。
注意：不是“优化器聪明”，而是数据物理上就存在那里。比如你建了联合索引 idx_name_age（name, age），那么这棵树的每个叶子节点就同时存了 name 值和 age 值——查 SELECT name, age FROM user WHERE name = 'Alice' 时，连主键都不需要，自然没有回表这回事。
EXPLAIN 中怎么确认覆盖索引生效了
看 Extra 字段是否出现 Using index。只要看到这个，说明 MySQL 确实只扫描了索引，没碰聚簇索引的数据页。
-
Using index：覆盖索引生效，无回表 -
Using where; Using index：也是覆盖索引，只是额外做了索引下推（ICP）过滤 -
NULL或Using where：大概率回表了（除非是主键查询）
特别注意：SELECT * 几乎永远无法触发覆盖索引，除非你建的索引包含所有列（包括主键），但这种设计既浪费空间又违背范式，不推荐。
哪些字段必须进索引才算“覆盖”
覆盖范围不止是 SELECT 列，还包括所有参与逻辑计算的字段：
-
WHERE中的过滤字段必须在索引里（否则连索引都走不上） -
ORDER BY字段如果不在索引中，即使SELECT覆盖了，也可能触发 filesort，甚至让覆盖失效 -
GROUP BY和HAVING同理，字段缺失会导致临时表或回表 - 隐式类型转换会让索引失效，比如
WHERE name = 123（name是字符串），哪怕name在索引里，也白搭
联合索引顺序对覆盖能力的影响
最左前缀原则不是限制“能不能用索引”，而是决定“能不能覆盖”。比如索引是 (a, b, c)：
-
SELECT a, b WHERE a = 1→ 覆盖 -
SELECT b, c WHERE b = 1→ 不覆盖（b不是最左，索引无法定位） -
SELECT a, c WHERE a = 1→ 覆盖（c是后缀列，B+ 树叶子节点里存着） -
SELECT a, b, c, id WHERE a = 1→ 如果没显式把id加进索引，就仍需回表取id（除非id就是主键且已包含在索引中）
真正容易被忽略的是：联合索引中未出现在最左位置的字段，即使物理上在叶子节点里（B+ 树结构决定的），也无法被高效定位——所以“覆盖”和“可定位”是两回事，必须同时满足。
