JOIN后GROUP BY慢的主因是中间结果集过大，应优先下推过滤条件、优化JOIN顺序、确保GROUP BY字段有合适索引，并用预聚合或物化减少冗余计算。
为什么JOIN后GROUP BY慢，而不是GROUP BY本身慢
绝大多数时候，性能卡点不在GROUP BY逻辑，而在JOIN生成的中间结果集太大。比如orders和order_items两表LEFT JOIN后按customer_id分组，若没加时间过滤，可能把几年历史订单全拉进来——哪怕最终只输出1000个客户统计，中间也处理了百万行。
用EXPLAIN ANALYZE（MySQL 8.0+）或EXPLAIN FORMAT=JSON看rows字段：如果JOIN输出行数远高于最终分组数（例如120万 → 832），说明大量数据白跑了。
- 高选择性条件（如
created_at > '2026-04-01'、status = 'paid'）必须下推到子查询或CTE里，不能写在最外层WHERE - 避免
SELECT *——它会强制MySQL先分组再回表取所有列，极大拖慢速度 - 如果只是要统计数量或金额，别带
order_items.product_name这类从表字段；真需要，改用MAX()或窗口函数预取
用子查询先分组，再JOIN关联维度信息
当聚合逻辑明确、关联字段较少时，把GROUP BY提前到单表或小结果集上，比先JOIN再分组更高效。典型场景：统计每个客户的订单总金额，再关联客户城市。
错误写法（先膨胀再聚合）：
SELECT c.city, SUM(oi.amount) FROM customers c JOIN orders o ON c.id = o.customer_id JOIN order_items oi ON o.id = oi.order_id WHERE o.created_at > '2026-04-01' GROUP BY c.city;
正确写法（先聚合再关联）：
SELECT c.city, t.total_amount FROM customers c JOIN ( SELECT o.customer_id, SUM(oi.amount) AS total_amount FROM orders o JOIN order_items oi ON o.id = oi.order_id WHERE o.created_at > '2026-04-01' GROUP BY o.customer_id ) t ON c.id = t.customer_id;
- 子查询中
GROUP BY o.customer_id只处理订单主键级聚合，数据量锐减 - 外层JOIN只走
customers和聚合结果两张小表，避免order_items全量参与连接 - 确保子查询里的
WHERE条件已过滤掉无效订单（如o.status != 'cancelled'）
驱动表选错会导致GROUP BY前数据量爆炸
优化器有时会把大表当驱动表，导致嵌套循环连接反复扫描千万行——这时STRAIGHT_JOIN比调索引更直接有效。
比如user_stats（小表，几万行）和logs（大表，上亿行）JOIN后按user_id分组，但优化器选logs为驱动表：
- 加
STRAIGHT_JOIN强制小表驱动：SELECT STRAIGHT_JOIN u.name, COUNT(*) FROM user_stats u JOIN logs l ON u.id = l.user_id GROUP BY u.name - 配合
EXPLAIN确认type是否从ALL变成ref或range，且rows显著下降 - 注意：
STRAIGHT_JOIN是硬编码执行顺序，表数据分布变化后可能失效，上线后需定期复查执行计划
GROUP BY字段没走索引？检查联合索引顺序和覆盖性
即使建了索引，GROUP BY a, b也要求索引是(a, b)，而非(b, a)或单独(a)。否则MySQL无法利用索引排序，只能建临时表+文件排序。
常见陷阱：
-
SELECT dept_id, name, COUNT(*) FROM user GROUP BY dept_id—— 若name不在索引里，即使dept_id有索引，也可能放弃使用（因需回表取name） -
ORDER BY方向与GROUP BY不一致（如GROUP BY a ASC, b ASC ORDER BY a ASC, b DESC），MySQL 5.7会触发Using filesort - 用
ORDER BY NULL显式禁用隐式排序，尤其当不需要结果有序时
真正省事的做法：确保GROUP BY字段顺序严格匹配联合索引，并把SELECT中所有非聚合列都包含进该索引最左侧。
