覆盖索引优先于聚簇索引，因二级索引叶子节点含全部查询字段，可避免回表、减少IO；EXPLAIN显示Using index即生效，与主键是否参与WHERE无关。
EXPLAIN 显示走的是二级索引，但 WHERE 条件和 SELECT 字段都落在主键上，为什么没选聚簇索引？
MySQL 不是“优先选择覆盖索引”，而是只要某个二级索引能覆盖查询所需的所有列（即构成覆盖索引），优化器大概率会跳过聚簇索引，哪怕主键也在查询中。根本原因不是偏好，是少一次 B+ 树查找 + 少一次随机 IO。
- 聚簇索引的叶子节点存整行数据，查
SELECT *或含非索引列时必须用它 - 但若
SELECT a, b FROM t WHERE c = ? AND d = ?，而你建了(c, d, a, b)这个联合索引，InnoDB 就能在二级索引叶子节点直接拿到a和b，无需再拿主键去聚簇索引里捞数据 —— 这就是回表省掉了
常见错误现象：
- 明明有主键等值条件，
EXPLAIN却显示key是某个idx_xxx，Extra是Using index，误以为“没走主键”是异常 - 删掉一个看似冗余的二级索引后，慢查询突然复现，实际是因为它此前恰好充当了覆盖索引
判断是否真为覆盖索引，只看三件事：
-
WHERE中所有过滤列，必须是该二级索引的最左前缀（例如索引(a, b, c)可用于WHERE a = ? AND b = ?，但不能用于WHERE b = ?） -
SELECT列、ORDER BY列、GROUP BY列、HAVING中涉及的列，全部包含在该二级索引定义中（顺序无关，但必须存在） - 该索引是
INFORMATION_SCHEMA.STATISTICS里真实存在的二级索引，不是主键索引（主键索引天然“覆盖”，但不算这里说的覆盖索引场景）
为什么覆盖索引比聚簇索引快？关键在 IO 次数
走聚簇索引查 SELECT a, b FROM t WHERE c = ?（假设 c 没索引）：全表扫描 or 主键范围扫描 → 大量页读取
走二级索引 (c, a, b)：B+ 树定位到叶子页 → 直接返回 a、b → 全程只访问索引页
- 二级索引更窄：不存
TEXT、BLOB、长VARCHAR等大字段，缓存命中率高 - 聚簇索引页可能分散在磁盘不同位置，而二级索引页更紧凑，顺序性更好
-
Using index在EXPLAIN中出现，就代表这次查询完全没碰聚簇索引的数据页
哪些情况会让覆盖索引失效？
- 查询用了
SELECT *，而二级索引没包含所有列 → 必须回表 → 优化器可能放弃它，转而用聚簇索引（尤其当表不大时） -
WHERE条件中有函数或表达式，如WHERE YEAR(create_time) = 2024→ 无法使用索引的最左前缀 → 覆盖失效 - 索引列上有隐式类型转换，比如
varchar字段用数字查询：WHERE mobile = 13800138000→ 索引失效，自然也谈不上覆盖 - 统计信息过期（
ANALYZE TABLE没跑），优化器误判二级索引查出来的行数太多，觉得回表成本反而高
真正容易被忽略的一点：覆盖索引对 ORDER BY 和 GROUP BY 同样生效。比如 SELECT a FROM t WHERE b = ? ORDER BY c，如果索引是 (b, c, a)，就能避免文件排序（Using filesort）。这不是锦上添花，是直接影响执行计划走向的关键杠杆。
