覆盖索引要求索引包含查询中所有字段（where、group by、select含聚合列），否则sum()/avg()需回表引发随机i/o；必须用b+tree联合索引，按等值→范围→分组→聚合顺序排列，并通过explain中“using index”确认生效。
能，但前提是聚合字段和过滤/分组字段必须同时出现在同一个联合索引中，且顺序合理；否则 SUM() 和 AVG() 会强制回表，性能断崖式下跌。
为什么 SUM() / AVG() 很难走覆盖索引
MySQL 的聚合函数本身不决定是否走索引，真正卡住的是「能否在索引里拿到所有需要的值」。只要查询中任一字段不在索引叶子节点里，就必须回表——而 SUM(c3) 这类操作一旦触发回表，就等于为每一行匹配结果都多一次随机 I/O。
-
SUM()和AVG()不像MIN()/MAX()那样能靠 B+ 树有序性跳查，它必须遍历所有满足条件的行 - 即使
WHERE c1 = 'X'走了索引，若c3不在该索引中，仍需用主键回表取c3值 - InnoDB 二级索引叶子节点只存「索引列 + 主键」，不存其他列；没被包含的字段，一律要回表
如何构建真正有效的覆盖索引
核心是让索引包含「所有参与 WHERE、GROUP BY、SELECT（含聚合字段）」的列，且按「等值 → 范围 → 分组 → 聚合字段」顺序排列。
- 错误示例：
CREATE INDEX idx_c1 ON test (c1)→ 只覆盖WHERE c1 = ?，c2和c3全部要回表 - 正确写法：
CREATE INDEX idx_cover ON test (c1, c2, c3)→ 支持WHERE c1 = ? AND c2 = ? GROUP BY c1+SUM(c3) - 更优组合（如需兼顾排序）：
CREATE INDEX idx_cover ON test (c1, c2, c3) INCLUDE (id)不生效 —— MySQL 不支持INCLUDE语法，必须显式写进索引定义 - 注意字段顺序：
c1（等值过滤）放最左；c2（可能用于 CASE WHEN 条件）居中；c3（被聚合）放最右 —— 这样 B+ 树才能按前缀高效定位并顺序读取
怎么确认真的用了覆盖索引
别只看 key 字段非空，重点盯 EXPLAIN 输出里的 Extra 和 rows：
- 出现
Using index（不是Using where; Using index）→ 真正覆盖，无需回表 -
rows值接近实际匹配行数（而非全表行数），说明索引有效裁剪了扫描范围 - 没有
Using temporary或Using filesort→ 表明分组和聚合未触发额外排序步骤 - 反例：
Extra: Using where; Using index+rows: 5000000→ 说明只是用索引避免回表，但仍在扫全索引，毫无优化效果
GROUP BY + SUM() 场景下的典型陷阱
哪怕你建了 (c1, c3) 索引，如果 SQL 写成 SELECT c1, SUM(c3) FROM test WHERE c2 = 0 GROUP BY c1，依然白搭 —— 因为 c2 不在索引里，MySQL 必须先扫出所有 c1 值，再逐行回表判断 c2 = 0，最后才聚合。
- 必须把过滤字段也塞进索引：
CREATE INDEX idx_c1_c2_c3 ON test (c1, c2, c3) - 注意区分度：如果
c1只有 3 个值，即使走了索引，也可能因重复键值太多导致大量页内扫描，rows显示偏高 -
AVG()本质是SUM() / COUNT()，所以对索引要求和SUM()完全一致，无需单独考虑 - 不要指望多个单列索引自动合并成覆盖效果 ——
INDEX(c1)+INDEX(c2)+INDEX(c3)≠ 覆盖索引
覆盖索引对聚合函数有效的关键，从来不是“有没有索引”，而是“索引里有没有把整条查询链路需要的数据都打包进去”。少一个字段，就多一次回表；多一次回表，I/O 开销就指数级增长。实际建索引前，务必用 EXPLAIN 对照着 SQL 的每个字段逐个验证。
