覆盖索引能加速GROUP BY查询的前提是SELECT、WHERE、GROUP BY及聚合字段全部落在同一索引中且顺序符合最左前缀原则；判断依据为EXPLAIN中key非空且Extra无Using temporary和Using filesort。
覆盖索引能显著加速 GROUP BY 查询，但前提是它真能“覆盖”——不是建了索引就行，而是必须让 MySQL 在索引页内完成全部分组与取值，不回表、不排序、不建临时表。
怎么判断当前 GROUP BY 是否走覆盖索引
直接看 EXPLAIN 输出的两个字段：key 和 Extra。如果 key 显示用了某个索引，且 Extra 中**没有** Using temporary 和 Using filesort，同时 SELECT 列（含 GROUP BY 字段）全部出现在该索引定义中，才算真正覆盖。
-
GROUP BY a, b+SELECT a, b, COUNT(*)→ 索引需为(a, b)或(a, b, c)，不能是(b, a) - 若
SELECT里有SUM(c)，那c也得进索引，否则要回表查c值，不覆盖 - 隐式类型转换会直接让索引失效：比如
user_id是BIGINT，但写成WHERE user_id = '123'，key就变NULL
覆盖索引列顺序怎么排才有效
顺序错了，索引就白建。核心逻辑是：WHERE 等值条件放最左，GROUP BY 字段紧随其后，聚合依赖的字段（如 SUM() 的参数）放末尾。
- 查询
SELECT region, COUNT(*) FROM sales WHERE status = 'active' GROUP BY region→ 索引应为(status, region)，不是(region, status) - 若还选了
AVG(price)，那就得扩展成(status, region, price) - 范围条件（如
created_at > '2025-01-01'）只能放等值列之后，且最多一个；再往后加字段，索引就无法继续用于排序或分组定位
GROUP BY 多字段时容易踩的坑
多字段分组本身不慢，慢在索引没对齐或语义理解错位。
-
GROUP BY category, status要求索引必须是(category, status)这种左前缀结构；(status, category)对大多数场景无效，除非你WHERE status = ?且GROUP BY status, category - 别在
GROUP BY里用函数：GROUP BY DATE(created_at)会让索引完全失效；MySQL 8.0 可建函数索引INDEX (DATE(created_at))，5.7 只能加生成列再索引 - 如果
SELECT出了非分组字段（如SELECT category, name FROM t GROUP BY category），即使加了索引，MySQL 也会拒绝执行（sql_mode=ONLY_FULL_GROUP_BY开启时）或返回不可靠值
ORDER BY NULL 是个被低估的开关
当 GROUP BY 后不需要结果有序，但执行计划里却出现 Using filesort，大概率是优化器默认加了隐式排序。加上 ORDER BY NULL 能明确关闭它。
- 例如
SELECT dept_id, COUNT(*) FROM emp GROUP BY dept_id ORDER BY NULL，可避免额外排序开销 - 注意：如果语句里同时有
GROUP BY a和ORDER BY b（b不在分组键里），ORDER BY NULL无效，仍会Using filesort - 这个技巧在汇总类报表（如后台统计页）中特别实用——数据要不要排序，由前端控制更合理
覆盖索引不是越宽越好，加字段意味着索引体积变大、写入变慢、缓存压力上升。真正关键的是把 WHERE 条件、GROUP BY 字段、聚合所需列这三者对齐，少一个环节，优化就断在半路。
