正确做法是先join再group by最后聚合；用left join保留主表分组，过滤条件放on或case中；显式处理null，如coalesce(weight, 0)和case when ... else 0 end。
用GROUP BY配合JOIN做分组求和，别在WHERE里过滤后再聚合
多表关联后分组求和，核心是先完成关联、再分组、最后聚合。常见错误是把过滤条件（比如status = 'done'）写在WHERE里，结果把某张表中无匹配的行整个丢掉，导致求和值偏低或缺失分组。
正确做法是：用LEFT JOIN保留主表全部分组维度，把业务过滤逻辑尽量放在ON子句或聚合内部处理。
- 若只统计“已确认订单”的销售额，且要按客户分组——
ON o.status = 'done'比WHERE o.status = 'done'更安全，尤其当客户在orders中无记录时，仍能保留客户行（SUM()为NULL或0） - 聚合内做条件判断更灵活，例如：
SUM(CASE WHEN o.status = 'done' THEN i.amount ELSE 0 END)，可同时统计“已确认”和“待确认”两列 -
WHERE适合全局硬性过滤（如时间范围），但不能替代ON或CASE做关联逻辑控制
避免SUM()被NULL拖垮：显式处理空值和权重缺失
一旦JOIN引入的字段（如权重、状态码、配置值）可能为NULL，amount * NULL直接得NULL，整行加权项失效，SUM()结果就变成NULL——这不是数据没值，是计算链断了。
必须主动兜底：
- 用
COALESCE(weight, 0)代替裸weight，防止权重缺失导致整组归零 - 用
CASE WHEN ... ELSE 0 END替代开放式的CASE WHEN ...，避免漏分支返回NULL - 若用
LEFT JOIN关联权重表，记得ON t.product_type = w.product_type AND w.effective_date ，否则可能匹配到过期权重或重复行
聚合字段与SELECT列表必须严格对齐
SQL标准要求：所有非聚合字段，必须出现在GROUP BY子句中。但实际执行时，MySQL 5.7默认允许“宽松模式”，PostgreSQL/SQL Server则直接报错ERROR: column "xxx" must appear in the GROUP BY clause。
别依赖MySQL的宽容。写法上要统一：
- 如果
SELECT里有a.region、b.category、SUM(a.sales)，那GROUP BY就得写a.region, b.category - 别写
GROUP BY 1,2——可读性差，且一旦调整SELECT顺序就崩 - 别把
ORDER BY字段塞进GROUP BY里凑数，它不参与分组逻辑
需要跨表分别聚合再合并？优先用CTE或子查询，别硬套JOIN
像“a表按班次求产量和，b表按班次求用料量和，合并成一张结果表”这种需求，强行用JOIN会隐含假设两张表班次完全一致。一旦某班次在a表有数据、b表没数据，INNER JOIN就直接丢掉该班次。
更稳健的写法是：
- 用
UNION ALL+ 标记字段拼成宽表结构（适合列数少、维度简单） - 用两个子查询分别
GROUP BY，再FULL OUTER JOIN（PostgreSQL/SQL Server支持；MySQL需用LEFT JOIN+RIGHT JOIN模拟） - 用
WITHCTE预计算，逻辑清晰且可复用，例如：WITH a_sum AS (SELECT 班次, SUM(产量) AS 产量总和 FROM a GROUP BY 班次),<br>b_sum AS (SELECT 班次, SUM(用料量) AS 用料量总和 FROM b GROUP BY 班次)<br>SELECT COALESCE(a.班次, b.班次) AS 班次, a.产量总和, b.用料量总和<br>FROM a_sum a FULL OUTER JOIN b_sum b ON a.班次 = b.班次;
真正容易被忽略的，是分组键的语义一致性——比如“班次”在a表是字符串'1班'，在b表却是数字1，外表看一样，JOIN却匹配不上。这种隐式类型差异，比语法错误更难排查。
