覆盖索引能跳过回表，因为InnoDB二级索引叶子节点只存索引列值和主键值，当SELECT、WHERE、ORDER BY等所有字段均包含在同一联合索引中且EXPLAIN显示Using index时，MySQL可直接从该索引获取全部数据，无需回聚簇索引查找整行。
覆盖索引为什么能跳过回表
因为 InnoDB 的二级索引叶子节点里，本来就存着「索引列值 + 主键值」。只要查询需要的所有字段（SELECT 列、WHERE 条件列、ORDER BY 或 GROUP BY 列）全都在这个索引定义里，MySQL 就能直接从这堆叶子节点里把结果拼出来，根本不用拿着主键再去聚簇索引里翻一遍。
这不是“优化器聪明”，而是数据物理存放方式决定的：二级索引不存整行，但只要它存的字段够用，就天然省掉第二次随机 IO。
怎么确认一次查询真的没回表
只看 EXPLAIN 输出里的 Extra 字段：
-
Using index→ 真覆盖，零回表 -
Using index condition→ 用了索引下推（ICP），但 SELECT 列不全在索引里，仍会回表 -
Using where或NULL→ 基本回表，或索引没被选中
别信“字段都在索引里”这种直觉判断。比如 INDEX (status, name)，执行 SELECT name FROM t WHERE status = 1 是覆盖；但加个 ORDER BY created_at，哪怕 created_at 在表里有索引，只要不在这个联合索引里，就会破功。
哪些写法看似覆盖、实则必然回表
常见陷阱不是建错索引，而是 SQL 写法绕过了覆盖能力：
-
SELECT *→ 二级索引不存所有列，除非表只有主键和索引列两列，否则必回表 -
SELECT UPPER(name) FROM t WHERE status = 1→ 函数表达式无法命中索引列原始值，强制回表（MySQL 8.0+ 需显式建函数索引） -
SELECT name FROM t WHERE name LIKE '%abc'→ 左模糊导致索引仅用于扫描，虽可能显示Using index，但若后续加ORDER BY id，优化器大概率放弃该路径 -
SELECT email FROM t WHERE city = 'shanghai'→ 索引是(name, city)，city不是最左列，索引根本用不上，更别说覆盖
联合索引列顺序怎么排才真正生效
顺序不是按 SELECT 字段写，而是按查询实际使用逻辑分层：
- 最左必须是
WHERE中的等值条件列（如status = ?），这是最左前缀生效的前提 - 接着放范围条件或排序字段（如
created_at > ?或ORDER BY updated_at DESC） - 最后补上纯“取值列”——即只出现在
SELECT里、没参与过滤或排序的字段（如name,email）
例如要支撑 SELECT name, email FROM order WHERE status = 1 ORDER BY created_at DESC，理想索引是 INDEX (status, created_at, name, email)。少一个 created_at，就可能触发 Using filesort；把 name 放最左，整个索引对这个查询就失效。
