索引覆盖是查询执行时的一种状态，指SELECT列和WHERE条件列全部被同一索引包含，MySQL可直接从该索引B+树叶子节点获取全部数据，无需回表查聚簇索引；其核心价值在于将二次随机I/O降为一次索引扫描，显著提升性能。
什么是索引覆盖，为什么它能跳过回表
索引覆盖不是一种特殊索引类型，而是查询执行时的一种状态：当 SELECT 列 + WHERE 条件列全部被一个索引包含时，MySQL 可直接从该索引 B+ 树的叶子节点读取全部所需数据，无需再用主键去聚簇索引里查整行——这个“避免回表”的过程就是性能提升的核心来源。
回表本质是二次 I/O：先走二级索引定位主键，再拿主键去聚簇索引查其他字段。尤其在大表、高并发场景下，磁盘随机读开销会被显著放大。而覆盖索引让整个查询变成一次索引顺序扫描（或范围扫描），I/O 量直降 50% 以上。
怎么确认你的查询是否触发了索引覆盖
唯一可靠方式是看 EXPLAIN 输出中的 Extra 字段：
- 出现
Using index→ 成功覆盖（注意：不是Using index condition，后者只是用了 ICP，仍可能回表） - 出现
Using where; Using index→ 也属于覆盖，说明 WHERE 条件在索引中完成过滤，且 SELECT 列全在索引里 - 只有
Using index condition或Using where→ 没覆盖，大概率要回表
示例：EXPLAIN SELECT name, age FROM users WHERE status = 1; 若 status 索引只含该列，而 name 和 age 不在其中，则不会出现 Using index。
如何设计能支撑覆盖的联合索引
关键不是“加字段”，而是按查询真实模式组织字段顺序：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
WHERE中的等值条件列放最左（如status = 1），遵循最左前缀原则 - 接着放
ORDER BY或GROUP BY列（如created_at），可顺便避免 filesort - 最后放
SELECT中需要的非条件列（如name,email），它们不参与索引查找，但必须存在才能覆盖 - 避免把低区分度列（如
gender）放在前面，否则索引选择性差，优化器可能弃用
反例：CREATE INDEX idx_cover ON orders (is_deleted, user_id, amount); —— 若 is_deleted 大部分为 0，这个索引几乎无效；应换为 (user_id, is_deleted, amount)，前提是 user_id 是高频等值过滤条件。
哪些写法会让索引覆盖失效
即使索引字段齐全，SQL 写法不对照样白搭：
- 对索引列使用函数或表达式：
WHERE UPPER(name) = 'ALICE'或WHERE YEAR(created_at) = 2024→ 索引无法做前缀匹配 - 隐式类型转换：
WHERE mobile = 13800138000（mobile 是 VARCHAR）→ MySQL 自动转成数字比较，导致索引失效 - 使用
SELECT *：哪怕你建了覆盖索引，只要表结构新增列，*就会引入未索引字段，强制回表 - 使用
OR连接不同字段：WHERE status = 1 OR type = 'vip'→ 很难命中同一联合索引，通常退化为全表扫描或索引合并
真正容易被忽略的是：覆盖索引对 NULL 值处理敏感。如果索引列允许 NULL，而查询中又没显式判断 IS NULL 或 IS NOT NULL，优化器有时会放弃使用该索引——哪怕逻辑上它本可覆盖。
