GROUP BY 慢主要因未走索引分组，触发 Using temporary 或 Using filesort；需索引字段顺序严格匹配 GROUP BY 且覆盖 WHERE 条件，仅查分组键和聚合结果，并确保分组离散度低。
GROUP BY 为什么慢？先看执行计划里有没有 Using filesort 或 Using temporary
MySQL 对 GROUP BY 的处理依赖是否能复用索引排序。如果索引不能同时满足分组字段顺序和排序需求，就会触发临时表和文件排序——这两个标记一出现，基本就说明没走对索引。尤其当 EXPLAIN 的 type 是 ALL 或 index（全索引扫描）时，即使加了索引也可能白搭。
索引字段顺序必须严格匹配 GROUP BY 字段顺序
MySQL 只能利用索引的最左前缀做分组，且字段顺序、方向（ASC/DESC）必须与 GROUP BY 子句完全一致。比如：
SELECT dept_id, status FROM orders GROUP BY dept_id, status;
对应索引必须是：INDEX(dept_id, status)。写成 INDEX(status, dept_id) 就无效；加了 ORDER BY status DESC 但索引是 dept_id ASC, status ASC，也会退化。
- 复合索引中，
GROUP BY字段必须从左到右连续出现，不能跳过中间字段 - 如果查询还有
WHERE条件，索引应把过滤字段放在最左，再接GROUP BY字段（例如WHERE category = ? GROUP BY dept_id, status→ 索引为INDEX(category, dept_id, status)） - MySQL 8.0+ 支持降序索引，如需
GROUP BY a DESC, b ASC，索引得显式声明为INDEX(a DESC, b ASC)，否则仍可能无法覆盖
避免 SELECT 中出现非分组字段或聚合函数外的列
开启 sql_mode=ONLY_FULL_GROUP_BY（默认启用）后，SELECT 列表里所有非聚合字段都必须出现在 GROUP BY 中，否则报错：Expression #1 of SELECT list is not in GROUP BY clause。这个限制不是性能问题，但会让人误以为加了索引就能随便选字段。实际上，一旦写了 SELECT * 或引入未分组字段，优化器大概率放弃索引分组，改走临时表。
- 只查分组键和聚合结果，例如：
SELECT user_id, COUNT(*) FROM log GROUP BY user_id - 不要在
SELECT里混用MAX(created_at)和裸字段ip（除非ip功能依赖于user_id，且启用了functional_dependence，但不建议依赖此行为） - 若真需要额外字段，优先用
ANY_VALUE()显式声明，但注意这不会提升性能，只是绕过语法检查
小数据量别硬套索引，大分组数反而让索引失效
索引优化 GROUP BY 的前提是：分组键重复度高、分组后结果集远小于原表行数。如果 GROUP BY id（主键），等于每行一个组，优化器会直接放弃索引分组，因为逐条回表比建临时表还贵。这时 EXPLAIN 会显示 type: index 甚至 ALL，但实际执行可能更慢。
- 用
SELECT COUNT(DISTINCT group_col) / COUNT(*) AS selectivity估算分组离散度；值越接近 1，索引收益越低 - 对超大表做分组统计，考虑预聚合（如汇总表 + 定时更新）或物化视图（MySQL 8.0 不原生支持，需用
CREATE TABLE ... AS SELECT模拟） - 某些场景下，强制使用索引（
FORCE INDEX）反而更差，务必对比EXPLAIN FORMAT=TREE中的 cost 估算
索引不是万能解药，GROUP BY 的瓶颈常藏在数据分布、字段选择性和执行路径判断里。真正有效的优化，往往是从 EXPLAIN 里看到 Using index for group-by 这一行开始的——其余都是干扰项。
