覆盖索引通过将JOIN的ON条件字段和SELECT字段组合建联合索引实现免回表，顺序须遵循最左前缀原则，避免大字段和冗余主键，配合EXPLAIN验证Using index。
为什么 JOIN 查询慢，但加了索引也没用？
因为普通索引只加速单表查找，JOIN 涉及多表匹配时，数据库仍要回表取字段——尤其当 SELECT * 或非索引字段出现在查询结果里，就会触发大量随机 I/O。
- 覆盖索引（Covering Index）本质是把查询需要的所有字段都“塞进索引结构”，让数据库不用查表就能返回结果
- 对
JOIN来说，关键不是给每张表单独建索引，而是为ON条件 +SELECT字段组合建联合索引 - MySQL 的
EXPLAIN中如果看到type=ref且Extra列含Using index，说明走的是覆盖索引；若出现Using where; Using join buffer，大概率没覆盖成功
ON 字段和 SELECT 字段怎么一起建联合索引？
顺序不能乱：先放 JOIN 条件字段（按 ON 中的顺序），再放 SELECT 中需要的非主键字段。MySQL 索引最左前缀原则决定了顺序直接影响是否命中。
- 例如：
SELECT u.name, u.email, o.status FROM users u JOIN orders o ON u.id = o.user_id，应在orders表上建(user_id, status)，在users表上建(id, name, email) - 别把
PRIMARY KEY再重复写进联合索引——InnoDB 主键自动包含在二级索引中，(id, name)实际等价于(id, name, id)，冗余 - 如果
WHERE还有其他条件（比如o.status = 'paid'），要把该字段放在联合索引最前面，否则无法利用索引下推（ICP）
哪些字段绝对不能放进覆盖索引？
大字段（TEXT、BLOB、长 VARCHAR）会显著拖慢索引构建和维护速度，还可能触发页分裂，得不偿失。
- MySQL 单个索引列长度限制为 767 字节（utf8mb4 下约 191 个字符），超长字段即使加了前缀索引，也无法被覆盖索引真正“覆盖”
-
SELECT COUNT(*)类聚合查询不需要覆盖索引——它只依赖索引行数，不取字段值 - 如果查询中有
ORDER BY或GROUP BY，对应字段也必须纳入联合索引，且顺序要匹配，否则会多出Using filesort或Using temporary
执行计划里没显示 Using index，但查询变快了，怎么回事？
可能是索引优化了连接顺序或减少了扫描行数，而非真正实现覆盖。覆盖索引只是提速手段之一，不是银弹。
- 检查
rows列是否明显下降——哪怕没Using index，只要驱动表选择更优、被驱动表匹配更精准，整体耗时也会降 - 注意统计信息是否过期：
ANALYZE TABLE能让优化器重新估算行数，避免选错索引或连接算法 - 某些场景下，加索引反而让查询更慢：比如小表（ 查询收益），或查询本身只占 DB 负载极小部分
覆盖索引有效性的边界很窄：字段要精、顺序要准、数据分布要稳。线上改索引前，一定在从库或影子库跑 EXPLAIN FORMAT=JSON 对比，别只看 type 和 rows，重点盯 key_length 和 filtered。
