覆盖索引的核心作用是让查询完全在索引中完成，不触碰数据页，直接解决回表带来的性能损耗；其原理是二级索引叶子节点存储索引列值和主键值，当SELECT、WHERE、ORDER BY或GROUP BY涉及的列全部被单个索引覆盖时，MySQL可直接从索引页读取全部数据，执行计划中Extra显示“Using index”即命中覆盖索引。
覆盖索引的核心作用，是让查询完全在索引中完成，不触碰数据页。它直接解决回表带来的性能损耗问题。
覆盖索引怎么起作用
InnoDB 的二级索引叶子节点只存索引列值 + 主键值。如果 SELECT 的字段、WHERE 的条件列、ORDER BY 或 GROUP BY 用到的列，全部被一个索引包含，MySQL 就能直接从索引页读出全部所需内容。
- 执行计划中 Extra 显示 Using index，说明命中覆盖索引
- 没有 Using where; Using index 或 Using filesort 等额外操作，代表流程最简
- 例如：
SELECT user_id, order_status FROM orders WHERE user_id = 1001，若存在INDEX idx_user_status (user_id, order_status)，就构成覆盖
回表为什么慢
回表本质是“一次索引查找 + 一次主键查找”的组合动作，而主键查找在物理上往往是随机 I/O。
- 二级索引查出 N 行匹配记录，就要发起 N 次聚簇索引查找（即 N 次回表）
- 聚簇索引数据按主键顺序存储，但二级索引扫描顺序与主键顺序通常不一致 → 回表访问的数据页高度离散
- 每多一次回表，就多一次磁盘寻道或 buffer pool 缓存未命中，I/O 成本非线性上升
- 500 万行扫描 + 回表，在机械盘场景下极易触发数万次随机读，响应时间飙升至数十秒
如何设计有效的覆盖索引
不是字段堆得越多越好，关键看查询模式是否稳定、写入压力是否可接受。
- 把 WHERE 条件列 放最左（满足最左前缀），再按 SELECT 列、ORDER BY / GROUP BY 列 顺序追加
- 避免冗余：如已有
(a, b, c)，再建(a, b)通常无必要；但(a, b, c)无法覆盖SELECT a, c ORDER BY b - 注意数据类型宽度：过长的 VARCHAR 或 TEXT 类型不宜放进索引，会显著增大索引体积、降低缓存效率
- 高并发写多读少的表，慎加宽覆盖索引——每次 INSERT/UPDATE 都要同步更新多个索引项
验证和定位是否用了覆盖索引
别只看有没有索引，要看执行时到底走没走通。
- 用
EXPLAIN FORMAT=TRADITIONAL查看 key 和 Extra 字段 -
type 是
ref或range，且 Extra 含 Using index，才是真覆盖 - 如果出现 Using index condition，说明用了索引下推（ICP），但未必覆盖；Using where 则大概率要回表
- 配合
SHOW PROFILE或 Performance Schema 观察Handler_read_next和Handler_read_rnd_next的比值，后者高说明回表频繁
