在MySQL复杂查询中，先JOIN多张表再做GROUP BY是常见写法，但当数据量增长后，这类语句往往出现临时表过大、排序耗时高的问题。其根本在于关联阶段会产生大量中间行，随后分组又要对这些膨胀后的数据做去重与聚合。调整执行顺序，改为先分组后连接，是降低运算量的有效思路。
为什么JOIN后的GROUP BY更耗资源
MySQL优化器在处理SELECT ... FROM a JOIN b ON ... GROUP BY a.col时，多数情况下会先执行连接操作。假设表a有1万行，表b有1万行，且是一对多关系，连接后可能生成几十万行的中间结果。随后GROUP BY需要对这几十万行建临时表或使用排序算法做分组，CPU和内存开销都显著高于直接对原表分组。
从执行计划看，EXPLAIN中若出现Using temporary; Using filesort，往往意味着分组与排序发生在连接之后。此时即便连接字段有索引，也仅能加速关联本身，无法避免宽表带来的后续成本。理解这一点，才能有针对性地改写查询。
先分组后连接的基本改写方式
核心思路是：在连接之前，利用子查询或派生表把每张需要聚合的表先按分组字段聚合成最小结果集，再让这些小结果集相互关联。这样参与JOIN的行数大幅减少，分组操作所处理的数据量也退回原始表级别。
例如原查询先关联订单表与用户表再做统计：
SELECT u.user_id, u.user_name, COUNT(o.order_id) AS order_cnt FROM orders o JOIN users u ON o.user_id = u.user_id GROUP BY u.user_id, u.user_name;
可改写为先对用户维度聚合订单，再关联用户表：
SELECT u.user_id, u.user_name, t.order_cnt FROM ( SELECT user_id, COUNT(order_id) AS order_cnt FROM orders GROUP BY user_id ) t JOIN users u ON t.user_id = u.user_id;
改写后，子查询t仅输出去重后的用户级聚合行，通常远小于orders表行数。之后与users的连接成本很低。若orders表在user_id上有索引，子查询分组也能利用松散索引扫描进一步提速。
适用场景与限制分析
该优化在星型模型报表、日志聚合、按维度统计等场景效果明显，尤其是事实表大、维度表小且分组基数低时。此时先分组能把事实表压缩成维度级别的摘要，连接几乎不增加负担。
但需注意：若GROUP BY字段来自多张表的组合，或聚合函数依赖连接后的行（如统计两表关联后的去重对），则无法简单下推。此外，改写可能改变执行顺序，需校验结果是否与业务一致，避免少算被过滤掉的关联行。通过对比EXPLAIN与采样数据可确认等价性。
配合索引与参数进一步提升
为子查询中的分组字段建立联合索引，如INDEX(user_id, order_id)，可让MySQL使用索引覆盖完成COUNT，无需回表。同时适当调大tmp_table_size与max_heap_table_size，减少内存临时表转磁盘的概率。
在复杂场景中，也可用STRAIGHT_JOIN固定驱动顺序，强制优化器先处理已分组的派生表。下例显式指定小表驱动：
SELECT STRAIGHT_JOIN u.user_name, t.order_cnt FROM ( SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id ) t JOIN users u ON t.user_id = u.user_id;
综上，先分组后连接通过缩减参与关联的数据规模，从源头降低GROUP BY运算量。结合索引与执行计划观察，能在不改业务语义的前提下显著改善慢查询。