MySQL中GROUP BY执行顺序为FROM/JOIN→WHERE→GROUP BY→HAVING→SELECT，优化关键在于前置过滤：WHERE阶段用索引过滤、ON中精简关联、避免HAVING替代WHERE，并确保分组字段有匹配的有序索引以减少临时表使用。
GROUP BY执行顺序决定优化切入点
MySQL的GROUP BY不是孤立操作，它嵌在完整的SQL执行链中：从FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT。这意味着优化不能只盯着GROUP BY本身，而要往前压——越早过滤掉无效行，分组时处理的数据就越少。
常见错误是把本该在WHERE里做的过滤挪到HAVING里，比如写HAVING COUNT(*) > 10却没在WHERE里先筛掉明显不符合业务逻辑的记录（如status != 'completed'）。这样MySQL得先把所有行分完组，再逐个判断，白白消耗内存和CPU。
-
WHERE阶段能用索引就绝不用HAVING——HAVING无法走索引，纯内存计算 - 时间范围、状态码、ID区间等确定性强的条件，必须放在
WHERE - 如果
JOIN后数据膨胀严重，优先在ON子句里加过滤（如ON a.id = b.id AND b.deleted = 0），比放到WHERE更早剪枝
索引是否命中直接决定用不用临时表
执行EXPLAIN时看到Extra列出现Using temporary，基本等于宣告这次GROUP BY要走临时表——轻则吃内存，重则落磁盘（当结果集超过tmp_table_size和max_heap_table_size较小值时）。根本原因通常是分组字段没索引，或索引不匹配。
理想情况是触发Using index for group by：要求分组字段有**有序索引**（B+树索引），且查询中没其他导致索引失效的操作（如对分组字段用函数、隐式类型转换）。
- 单列分组：给该列建普通索引即可，例如
GROUP BY goods_name→INDEX(goods_name) - 多列分组：按
GROUP BY的列顺序建联合索引，例如GROUP BY department, job_title→INDEX(department, job_title) - 避免在分组字段上做运算：
GROUP BY DATE(pay_time)会强制全表扫描，应改用范围查询+索引：WHERE pay_time >= '2026-01-01' AND pay_time
SELECT列表错误会直接触发全量分组
MySQL 5.7+默认开启ONLY_FULL_GROUP_BY模式，一旦SELECT里出现未聚合也未出现在GROUP BY中的字段，查询直接报错。这不是bug，而是防止返回不可靠数据的保护机制。
典型错误写法：SELECT dept, employee_name, COUNT(*) FROM emp GROUP BY dept。这里employee_name对每个部门可能有多个值，MySQL不知道该取哪一个——强行执行会导致结果随机，线上环境极易引发数据不一致。
- 正确做法只有两种：要么删掉
employee_name，要么把它包进聚合函数，如MAX(employee_name)或GROUP_CONCAT(employee_name) - 别名不能用于
GROUP BY，GROUP BY cnt会报错，必须写原始表达式GROUP BY COUNT(*)或列序号GROUP BY 2（但后者可读性差，不推荐） - 如果业务真需要“每个分组里某字段的任意一个值”，用
ANY_VALUE()函数明确声明意图，而非关掉ONLY_FULL_GROUP_BY
ORDER BY和GROUP BY共用索引才能免排序
MySQL 8.0起取消了GROUP BY的隐式排序，如果后续跟了ORDER BY，且字段顺序与GROUP BY不一致，就会额外触发Using filesort。尤其当分组结果集大时，这个排序开销非常可观。
最省事的方案是让ORDER BY复用GROUP BY的索引。例如GROUP BY department, job_title后想按相同顺序排序，直接写ORDER BY department, job_title即可命中索引；但如果写成ORDER BY job_title, department，哪怕字段完全一样，顺序一变，索引就失效。
- 若必须按不同顺序排序，优先考虑在应用层做，而不是让MySQL重复排序
- 分组后只取Top N时，
LIMIT必须放在ORDER BY之后，否则MySQL可能先排序再截断，浪费计算 - 注意
SELECT里用了DISTINCT也会干扰索引使用，和GROUP BY语义重叠时应二选一
EXPLAIN输出里的type、rows、key和Extra四列才是关键信号——它们不会说谎，但需要你对照执行顺序去读。很多问题表面看是GROUP BY慢，根子却在JOIN没控制好数据量，或者WHERE条件写成了全表扫描。 
