覆盖索引能避免回表是因为查询所需字段全部包含在索引B+树叶子节点中，MySQL可直接从中取值，无需回主键索引查找整行数据。
覆盖索引为什么能避免回表
因为查询所需的所有字段，都包含在索引的 B+ 树叶子节点里，MySQL 直接从索引中取值，不用再回到主键索引（聚簇索引）里查整行数据。
回表是性能杀手：一次查询可能触发多次随机 IO。覆盖索引把“索引查找 + 回表”压缩成“纯索引查找”，尤其对大表、高并发场景效果明显。
- 必须确保
SELECT列、WHERE条件列、ORDER BY列、GROUP BY列，全部被单个索引“覆盖” -
SELECT *几乎不可能走覆盖索引——除非你建的是主键索引，但那不算“覆盖”，只是本来就在聚簇索引里 - 注意隐式字段：比如
ORDER BY id时，如果id不在联合索引里，就会破环覆盖性
怎么判断一个查询是否用了覆盖索引
看 EXPLAIN 输出里的 Extra 字段是否含 Using index —— 注意不是 Using index condition（那是 ICP，不等于覆盖）。
-
type是ref或range同时Extra有Using index，才是真覆盖 - 如果
Extra出现Using where; Using index，说明 WHERE 条件用了索引下推，且字段全在索引里，仍属覆盖 - 用
SHOW INDEX FROM table_name确认索引列顺序，覆盖依赖最左前缀，顺序错就失效
联合索引设计时容易漏掉的字段
只顾着优化 WHERE 条件，忘了 SELECT 和排序字段，结果索引建了也白搭。
- 例如查询
SELECT name, email FROM user WHERE status = 1 ORDER BY created_at DESC，理想索引是(status, created_at, name, email) -
ORDER BY字段必须紧跟在WHERE等值条件之后；如果是范围查询（如status > 0），后续字段无法用于排序，更别提覆盖 - 避免冗余：如果
email已在索引末尾，就别再单独为它加一列；但也不要为了省一列，把常用查询字段砍掉
覆盖索引在 COUNT 查询中的典型误用
很多人以为 COUNT(*) 自动走覆盖索引，其实只在某些条件下成立——关键看引擎和索引结构。
- InnoDB 下，
COUNT(*)无WHERE时默认走主键索引，不走二级索引；想让它走覆盖，得写成COUNT(1)或COUNT(pk)并配合非主键索引 - 如果建了
INDEX (a, b)，SELECT COUNT(a) FROM t WHERE a = 1可覆盖；但SELECT COUNT(*)仍可能回表，除非明确用SELECT COUNT(a) - 注意 NULL：
COUNT(col)会忽略NULL值，而COUNT(*)不会——字段是否允许 NULL，直接影响覆盖后语义是否一致
覆盖索引不是银弹，它让查询更快，但也让索引更宽、写入更慢、内存占用更高。真正难的不是建索引，是判断哪些查询值得为它多存几份字段副本。
