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这一行开始的——其余都是干扰项。
