SQL中JOIN与聚合函数联用最易错的是数据行膨胀导致聚合失真：一对多JOIN会复制主表行，使COUNT/SUM统计关联后组合行而非主表本身；须分清WHERE（聚合前过滤）与HAVING（聚合后过滤），避免笛卡尔积和NULL隐式处理陷阱。
SQL 中 JOIN 和聚合函数（如 COUNT、SUM、AVG 等）一起用时，最容易出错的地方不是语法写错，而是逻辑理解偏差——特别是 JOIN 导致的数据行膨胀 会悄悄扭曲聚合结果，而你可能根本没意识到。
JOIN 后直接 GROUP BY 容易“多算”
当主表和从表是一对多关系时，JOIN 会把主表的每一行“复制”成多行，再做 COUNT 或 SUM，结果就不是你想要的“主表记录数”或“主表字段总和”，而是“关联后所有组合行”的统计。
比如：查每个部门有多少员工，同时显示部门平均薪资：
错误写法：SELECT d.name, COUNT(e.id), AVG(e.salary) FROM dept d LEFT JOIN emp e ON d.id = e.dept_id GROUP BY d.id, d.name;
问题：如果一个部门有 5 个员工，这条语句会生成 5 行相同部门信息，COUNT(e.id) 是 5 没问题，但如果你后续加了 WHERE 过滤员工（比如只统计在职员工），又忘了同步影响分组逻辑，结果就偏了。
关键点：GROUP BY 的字段必须覆盖所有非聚合列；LEFT JOIN + COUNT(e.id) 会把无员工的部门计为 0，但 COUNT(*) 会算出 1（因为 LEFT JOIN 仍保留 dept 行），务必分清。
聚合前过滤 vs 聚合后过滤，位置决定结果
WHERE 在 JOIN 之后、GROUP BY 之前执行，HAVING 在 GROUP BY 之后、聚合完成之后执行。想筛“平均薪资 > 8000 的部门”，必须用 HAVING；若误用 WHERE e.salary > 8000，就变成“先筛出高薪员工，再按部门聚合”，结果完全不一样。
- WHERE e.status = 'active' → 先剔除离职员工，再聚合（正确用于行级条件）
- HAVING AVG(e.salary) > 8000 → 对每个部门算完平均值再筛选（正确用于聚合结果条件）
- WHERE AVG(e.salary) > 8000 → 语法错误！聚合函数不能出现在 WHERE 中
多表 JOIN + 多重聚合，小心笛卡尔积式膨胀
比如查部门、员工数、项目数，若部门-员工-项目三者没有明确的层级或限制关系，直接 JOIN 三个表极易产生隐式笛卡尔积。
典型陷阱：
SELECT d.name, COUNT(e.id), COUNT(p.id) FROM dept d LEFT JOIN emp e ON d.id = e.dept_id LEFT JOIN project p ON d.id = p.dept_id GROUP BY d.id, d.name;
如果某部门有 3 名员工、4 个项目，这段 SQL 实际会生成 3×4=12 行组合，COUNT(e.id) 和 COUNT(p.id) 都变成 12，而不是你期待的 3 和 4。
解法不是硬套 DISTINCT（COUNT(DISTINCT e.id) 可行但性能差），而是拆成子查询或使用相关联的聚合子句：
- 用子查询分别统计员工数、项目数，再 JOIN 到 dept 表
- 用窗口函数（如 COUNT() OVER (PARTITION BY ...)）避免多次 JOIN
- 在业务层接受“分步查”，比写出高风险单条 SQL 更可靠
NULL 值参与聚合，结果可能静默失真
JOIN 产生的 NULL（如 LEFT JOIN 没匹配上的右表字段）在 SUM、AVG 中会被自动忽略，但 COUNT(*) 仍会计数，COUNT(列名) 会跳过 NULL —— 这些行为看似合理，但在嵌套逻辑中容易埋雷。
例如：统计每个部门的“平均带绩效奖金的员工薪资”，如果用 AVG(e.bonus)，而 bonus 字段本身允许 NULL，那 AVG 就只算有奖金的人；但如果你本意是“所有员工的平均奖金额（无奖金算 0）”，就得显式写成 AVG(COALESCE(e.bonus, 0))。
更隐蔽的是：LEFT JOIN 后对右表字段 COUNT(e.id) 得到的是匹配数，COUNT(*) 得到的是左表行数，两者不等说明存在空匹配 —— 这个差异本身就能帮你发现数据关联异常。
