覆盖索引是查询优化效果，联合索引是物理存储结构。覆盖索引能彻底消除回表，联合索引仅在查询列包含在索引中时才避免回表。设计索引时优先满足覆盖索引条件，同时遵守联合索引的最左前缀原则。
先说结论：覆盖索引是“查询无需回表”的效果，联合索引是“多列组合”的索引结构，二者属于效果与手段的关系。
- 适合：高频查询且字段固定的场景，如报表统计、列表页。
- 重点看：EXPLAIN 结果中 Extra 列是否显示 Using index。
- 别忽略：索引列顺序需符合最左前缀原则，避免 SELECT *。
命令速用版
使用 EXPLAIN 命令分析 SQL 执行计划，确认是否命中覆盖索引。
EXPLAIN SELECT user_id, status FROM orders WHERE user_id = 1001;查看输出结果中的 Extra 字段，若显示 Using index 则命中覆盖索引，若显示 Using where 或为空则可能涉及回表。
为什么会这样
联合索引是物理结构，覆盖索引是查询场景，只有查询列全部在索引树上时才不回表。InnoDB 引擎中，普通索引叶子节点存储索引列值和主键值，聚簇索引叶子节点存储整行数据。普通查询通过普通索引找到主键后，需再次访问聚簇索引获取完整行数据， this process is called 回表。覆盖索引因查询所需字段均在普通索引叶子节点中，无需二次访问聚簇索引，从而减少磁盘 I/O 和 CPU 开销。
分步处理
第一步：识别高频查询语句，提取 WHERE、SELECT、ORDER BY 涉及的所有字段。
第二步：创建联合索引，将筛选字段放在最左侧，返回字段紧随其后。例如查询 user_id 和 status，创建索引 (user_id, status)。
CREATE INDEX idx_user_status ON orders (user_id, status);第三步：修改 SQL 语句，确保 SELECT 子句仅包含索引列，禁止使用 SELECT *。
第四步：执行 EXPLAIN 验证，确认 type 为 ref 或 range，Extra 显示 Using index。
怎么验证是否生效
检查 EXPLAIN 输出结果的 Extra 列，出现 Using index 表示命中覆盖索引。若 Extra 列显示 Using index condition 或 Using where，说明发生了回表或索引下推。同时观察 Handlers 状态值，覆盖索引执行后 Handler_read_next 和 Handler_read_key 次数应显著低于全表扫描。
SHOW STATUS LIKE 'Handler_read%';对比优化前后的 Handler_read_rnd_next 值，若该值未大幅增加，说明减少了回表操作。
常见坑
避免在覆盖索引场景中使用 SELECT *，这会强制回表查询所有列。联合索引必须遵循最左前缀原则，查询条件不从最左列开始会导致索引失效。索引列上进行函数运算或类型隐式转换会破坏覆盖索引效果。索引字段过多会导致索引树过大，降低写入性能并占用更多内存。
常见问题
单列索引能形成覆盖索引吗？
可以，只要查询字段仅包含该单列索引列和主键，无需联合索引也能覆盖。
联合索引一定能避免回表吗？
不一定，只有 SELECT 查询的字段全部包含在联合索引中时，才能避免回表。
覆盖索引会影响写入性能吗？
会，索引列越多，维护索引树的开销越大，插入和更新操作变慢。
索引下推和覆盖索引是一回事吗？
不是，索引下推是在存储引擎层过滤条件，覆盖索引是直接从索引返回数据，二者可同时生效。
参考来源
1. CDA 干货 - 联合索引与覆盖索引：本质区别、实战场景与 MySQL 性能优化指南
2. 知乎 - Mysql 的覆盖索引和联合索引的区别在哪里？
3. CSDN 博客 - 【MySQL】索引类型优化：联合索引与覆盖索引的实践
4. CSDN 博客 - 联合索引、覆盖索引和索引下推
5. 博客园 - 联合索引和覆盖索引有什么区别