覆盖索引能显著提升大表分组查询性能，前提是GROUP BY字段、WHERE条件字段和SELECT中所有非聚合字段必须全部落在同一联合索引中；漏掉任意一个，就仍要回表。
覆盖索引能显著提升大表分组查询性能，但前提是 GROUP BY 字段、WHERE 条件字段和 SELECT 中所有非聚合字段必须全部落在同一联合索引中；漏掉任意一个，就仍要回表。
为什么大表 GROUP BY 容易慢？不只是排序问题
很多人以为 GROUP BY 慢是因为 Using filesort，其实更隐蔽的瓶颈是回表。比如 SELECT user_id, COUNT(*) FROM order WHERE status = 'paid' GROUP BY user_id，即使 status 和 user_id 都有索引，只要索引不包含两者组合，MySQL 就得：先用索引扫出满足 status = 'paid' 的主键 → 再逐个回表取 user_id → 最后才分组。每行都触发一次随机 I/O，10 万行就是 10 万次磁盘寻道。
关键点在于：GROUP BY 字段必须参与索引构建，且不能依赖回表后取值；否则优化器宁可全表扫描也不走低效索引。
- 执行
EXPLAIN后若Extra出现Using temporary; Using filesort，说明既没覆盖也没利用索引有序性 - 若
Extra是Using index，但type是index（全索引扫描），说明索引太宽或顺序不合理，可能比 ref 扫描还慢 - 区分度低的字段（如
status只有 3–5 个值）放索引最左时，容易让优化器放弃使用该索引——它预估扫描行数太多，不如直接走聚簇索引
如何设计覆盖索引让 GROUP BY 直接走索引
目标不是“能分组”，而是“分组过程完全在索引页内完成”。这意味着索引必须同时满足三类字段需求：过滤（WHERE）、分组（GROUP BY）、输出（SELECT 非聚合列）。
例如高频查询：SELECT region, COUNT(*), AVG(amount) FROM sales WHERE year = 2025 GROUP BY region，正确索引是：CREATE INDEX idx_year_region ON sales (year, region)。
-
year放最左：等值过滤，符合最左前缀 -
region紧跟其后：既是 GROUP BY 字段，又出现在 SELECT 中，确保分组键和输出值都从索引叶子节点直接读取 - 不需要把
amount加进索引——它是聚合字段，MySQL 只需在扫描索引过程中累加，不依赖单行值 - 如果还要查
MAX(created_at)，而created_at不在索引里，就会回表；此时应扩展索引为(year, region, created_at)，但要注意created_at类型是否支持高效索引（如 DATETIME 没问题，TEXT 不行）
EXPLAIN 看懂是否真覆盖，别被 Using index condition 欺骗
EXPLAIN 的 Extra 列是唯一可信依据，但必须认准确切值：Using index ✅ 表示纯覆盖；Using index condition ❌ 表示用了索引下推（ICP），但后续仍需回表取数据——对 GROUP BY 毫无帮助。
典型误判场景：SELECT user_id FROM log WHERE url LIKE '%/api/v2/%' GROUP BY user_id。即使有 INDEX(url, user_id)，因为 LIKE '%...' 左模糊导致索引失效，type 变成 ALL 或 index，Extra 里根本不会出现 Using index。
- 先确认
type是ref、range或eq_ref，再看Extra - 如果
SELECT中用了函数，如UPPER(user_id)，哪怕user_id在索引里，也无法覆盖——MySQL 8.0+ 需显式建函数索引：CREATE INDEX idx_upper_user ON log ((UPPER(user_id))) -
NULL值陷阱：若region允许为 NULL，而查询写成WHERE region IS NULL GROUP BY region，某些 MySQL 版本（尤其是 5.7）可能无法稳定走覆盖索引，建议统一用默认值替代 NULL
分页 + GROUP BY 场景下覆盖索引的取舍
带 LIMIT 的分组查询（如统计 TOP 10 用户）最容易误用覆盖索引。例如：SELECT user_id, COUNT(*) c FROM event WHERE dt >= '2026-05-01' GROUP BY user_id ORDER BY c DESC LIMIT 10。
此时仅建 (dt, user_id) 不够：虽然能避免回表取 user_id，但 ORDER BY COUNT(*) 是聚合后排序，无法用索引有序性加速；优化器仍会建临时表、文件排序。真正有效的做法是两步走：
- 先用覆盖索引快速聚合：
CREATE INDEX idx_dt_user ON event (dt, user_id)，确保GROUP BY过程不回表 - 但不要指望靠这个索引省掉
ORDER BY ... LIMIT开销；如需高频 TOP N，考虑物化汇总表或引入 Redis 缓存计数 - 切忌为了“看起来覆盖”而堆砌字段，比如把
event_type、ip等大字段塞进索引——索引体积膨胀后，缓冲池命中率下降，反而拖慢整体查询
覆盖索引对 GROUP BY 的价值非常明确：它消灭的是“每行都要回表取分组键”这个最原始的 I/O 放大器。但一旦涉及聚合后排序、多层嵌套或大结果集截断，就得跳出索引思维，直面算法和架构约束。
