GROUP BY后数据量暴增主因是前置JOIN未控制关联基数，如orders与order_items一对多再JOIN customers时缺乏过滤或去重，导致笛卡尔积式膨胀；应优先在聚合前用子查询收拢“一”侧数据、将右表过滤条件写入ON而非WHERE，并善用窗口函数避免行数扩张。
为什么GROUP BY后数据量暴增？
这不是GROUP BY本身的问题，是它前面的JOIN没控制好关联基数。比如orders和order_items一对多，再JOIN一个customers，如果没加限制条件或去重逻辑，GROUP BY order_id前就已产生重复组合——每个订单项都会拉一次客户信息，结果就是笛卡尔积式膨胀。
常见错误现象：COUNT(*)远大于预期、SUM(amount)翻倍、查询慢到超时。
- 先检查JOIN链上每对表的关联字段是否都有索引，尤其
order_items.order_id和customers.id - 确认所有JOIN条件都写全了，比如漏了
AND customers.status = 'active'，可能把无效客户也拉进来 - 如果只是要客户名称，别用
LEFT JOIN customers，改用子查询或SELECT ... FROM orders o JOIN (SELECT id, name FROM customers) c ON o.customer_id = c.id
用DISTINCT还是子查询做聚合前置？
DISTINCT在GROUP BY之后去重，治标不治本；真正该做的是在聚合前把“一”侧数据收干净。比如统计每个客户的订单数和总金额，客户维度必须唯一，否则GROUP BY customer_id仍会因JOIN带入重复行而失真。
使用场景：需要按“主表某字段”分组，但关联表存在一对多关系，且你只关心主表粒度。
- 优先用子查询：把
order_items按order_id先聚合（如SUM(quantity)），再JOIN回orders，避免扩散 - 别在SELECT里对多对字段用
DISTINCT，比如SELECT DISTINCT customer_name, COUNT(*)——这会让引擎先膨胀再收缩，代价更大 - 如果必须保留明细字段（如最新下单时间），用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC)筛出单条，再JOIN
WHERE和ON的位置怎么影响结果？
LEFT JOIN中，过滤条件放WHERE和放ON有本质区别：放WHERE会把NULL行整个踢掉，等效于INNER JOIN；放ON才保持左表完整性。但更关键的是，放错位置会导致本该被过滤的中间结果参与笛卡尔积。
参数差异：ON a.id = b.a_id AND b.status = 'shipped' vs ON a.id = b.a_id WHERE b.status = 'shipped'。
- 前者：只关联已发货的
b记录，不会产生未发货的空匹配，JOIN结果集更小 - 后者：先全量LEFT JOIN，再过滤，
b.status IS NULL的行也被保留，但WHERE又把它干掉了——中间过程白跑了，还可能触发笛卡尔积 - 外连接中，涉及右表的过滤一律写进
ON，除非你明确要丢弃左表无匹配的行
窗口函数能绕开JOIN爆炸吗？
能，而且往往更清晰。当你要在主表行上“附带”来自关联表的聚合值（比如每个订单显示其客户总消费额），直接JOIN会把客户总消费复制到每条订单项，造成冗余；用窗口函数可避免落地中间笛卡尔积。
性能影响：窗口函数在聚合层计算，不扩大行数，内存压力小，但需注意分区键是否走索引。
- 替代方案示例：
SELECT order_id, customer_id, SUM(amount) OVER (PARTITION BY customer_id) AS total_spent FROM orders - 不能替代JOIN的场景：需要取关联表的非聚合字段（如客户地址），窗口函数无法返回具体哪一行的值
- 兼容性注意：MySQL 8.0+、PostgreSQL、SQL Server 2012+支持，旧版MySQL只能靠变量模拟，不稳定
最容易被忽略的是JOIN顺序本身——不是语法从左到右执行，而是优化器决定。哪怕写了A JOIN B JOIN C，也可能先算B JOIN C。所以别依赖书写顺序，用EXPLAIN看实际执行计划，重点盯rows列和type是不是ALL或index。
