跨表聚合出错主因是未明确分组维度与聚合字段，须以统计目标定主表、用left join保完整性，group by需严格匹配select非聚合表达式，count(*)与count(字段)语义不同，多表join需防数据膨胀。
JOIN之前先确认主表和统计维度
跨表聚合出错，八成是因为没想清楚「按哪张表的字段分组」和「哪些字段需要聚合」。比如要统计每个部门的员工平均薪资，department 是维度来源，employee 是数据来源，那就该以 department 为主表 LEFT JOIN employee，而不是反过来——否则部门没人的记录会直接丢掉。
常见错误现象：GROUP BY department.id 却在 SELECT 里写了 employee.name，报错“不在 GROUP BY 中”，本质是混淆了分组键和明细字段。
- 统计目标决定主表：要“每个用户订单数”，主表是
user；要“每笔订单商品总价”，主表是order - LEFT JOIN 保主表完整；INNER JOIN 只留匹配行，容易漏统计项
- 所有非聚合字段（如
dept.name、user.email）必须出现在GROUP BY中
GROUP BY 字段必须和SELECT非聚合列严格一致
MySQL 5.7+ 和 PostgreSQL 严格要求：只要 SELECT 里有非聚合表达式（比如 UPPER(dept.name)），GROUP BY 就得写一样的表达式，不能只写 dept.name。很多开发者卡在这儿，以为“名字一样就行”，其实数据库认的是表达式树。
示例错误写法：
SELECT dept.id, UPPER(dept.name), COUNT(emp.id)<br>FROM department dept<br>LEFT JOIN employee emp ON dept.id = emp.dept_id<br>GROUP BY dept.id, dept.name -- ❌ 这里必须写 UPPER(dept.name)
- 用别名简化可读性，但
GROUP BY仍需写原始表达式（标准 SQL 不支持用别名） - PostgreSQL 支持
GROUP BY 1,2按位置引用，但可读性差，线上慎用 - 如果只按主键分组（如
dept.id），且其他字段都来自同一张主表（如dept.name），部分 MySQL 版本允许省略，但别依赖——SQL 标准不保证
COUNT(*) vs COUNT(字段) 的语义差异直接影响结果
跨表聚合时，COUNT(*) 统计的是 JOIN 后的行数，而 COUNT(emp.id) 会自动忽略 emp.id IS NULL 的行（比如 LEFT JOIN 没匹配上的部门）。这导致“部门人数”可能为 0，也可能被算成 1（如果误用了 COUNT(*)）。
典型场景：统计每个部门的员工数 + 平均薪资。COUNT(*) 会把空部门也记为 1 行（因主表行存在），但 COUNT(emp.id) 才是真实人数。
- 要“关联记录数”，用
COUNT(关联表主键)（如COUNT(order.id)） - 要“主表记录数”，用
COUNT(*)，但需确保 JOIN 方式不膨胀行数（警惕一对多未去重） -
AVG(emp.salary)自动跳过 NULL，等价于AVG(COALESCE(emp.salary, 0))？不等价——前者分母是非 NULL 行数，后者分母是全部行数
JOIN 多对一或一对多时，聚合前务必去重
一张订单多个商品，一张商品多个库存记录——这类链式 JOIN 容易让一行订单变成多行，导致 SUM(order.amount) 被重复累加。这不是 GROUP BY 的问题，是 JOIN 本身放大了数据量。
解决思路不是硬套子查询，而是优先用 DISTINCT 在聚合内去重（简单场景），或拆成独立子查询（复杂逻辑）：
- 简单去重：
COUNT(DISTINCT order.id)、SUM(DISTINCT order.amount)—— 仅当 amount 唯一时可用 - 更可靠方式：先用子查询聚合明细（如
SELECT order_id, SUM(price) AS total FROM order_item GROUP BY order_id），再 JOIN 主表 - 警惕 WHERE 条件写在 JOIN 后的 ON 子句里：比如
ON o.id = oi.order_id AND oi.status = 'shipped'，这会影响 LEFT JOIN 的 NULL 补全逻辑
跨表聚合真正难的不是语法，而是厘清“这一行在 JOIN 后代表什么业务含义”。字段看着都在，结果对不上，大概率是某张表的粒度比你想的更细，或者 NULL 处理没对齐。
