根本原因是JOIN先导致数据行膨胀（如1对多使主表1行变N行），再GROUP BY是在错误粒度上聚合；正确做法是先用子查询或CTE对多端表预聚合，再JOIN，确保关联前每键仅一行。
为什么不能直接在 JOIN 后写 GROUP BY
很多人写 SQL 时习惯先 JOIN 多张表，再用 GROUP BY 聚合，结果发现统计结果翻倍或不准。根本原因是：关联操作会先「膨胀」数据（比如 1 对多关系让主表一行变多行），再聚合就不是你想要的原始粒度了。
正确思路是——把聚合逻辑「收口」到子查询或 CTE 里，确保关联前每张表只保留聚合后的单行结果。
用子查询预聚合再 JOIN（兼容所有 SQL 方言）
这是最通用、最可控的方式。核心是把聚合逻辑封装进一个带别名的子查询，然后像普通表一样参与 JOIN。
-
SELECT中只能引用子查询里明确SELECT出来的字段，不能引用原表未聚合的列 - 子查询必须有别名（如
AS sales_summary），否则多数数据库报错ERROR: subquery in FROM must have an alias - 如果聚合结果要和主表按非主键字段关联（比如按日期范围匹配），需注意子查询中该字段是否已保留且类型一致
SELECT u.name, s.total_amount, s.order_count FROM users u LEFT JOIN ( SELECT user_id, SUM(amount) AS total_amount, COUNT(*) AS order_count FROM orders WHERE status = 'paid' GROUP BY user_id ) AS s ON u.id = s.user_id;
用 CTE 提升可读性（推荐 PostgreSQL / SQL Server / BigQuery）
CTE 不是语法糖，它能清晰表达「先算什么、再连什么」的执行意图，也方便复用同一聚合结果多次关联。
- CTE 中的
GROUP BY必须覆盖所有非聚合字段，否则报错column "xxx" must appear in the GROUP BY clause - 不要在 CTE 里写
ORDER BY—— CTE 不保证顺序，后续查询需显式排序 - 如果 CTE 结果集很大，部分数据库（如 MySQL 8.0+）支持
MATERIALIZED提示，但默认仍是 inline 展开，性能未必优于子查询
WITH user_sales AS ( SELECT user_id, SUM(price) AS revenue FROM order_items oi JOIN orders o ON oi.order_id = o.id WHERE o.created_at >= '2024-01-01' GROUP BY user_id ) SELECT u.email, us.revenue, p.plan_name FROM users u LEFT JOIN user_sales us ON u.id = us.user_id LEFT JOIN plans p ON u.plan_id = p.id;
关联后聚合的例外场景：只有当关联不改变分组粒度时才安全
极少数情况下，你可以先 JOIN 再 GROUP BY，前提是关联表对主表是「1 对 1」且无重复匹配（例如关联维表 user_profiles，每人只有一条记录）。
- 务必确认外键约束存在，或手动加
DISTINCT/MAX()等去重逻辑，否则隐式重复会污染聚合结果 - 即使当前是 1:1，未来加了新业务逻辑（如允许用户有多个 profile）就会突然出错，维护成本高
- 比起依赖约束，显式预聚合更可靠，尤其在报表类 SQL 中
真正容易被忽略的是：聚合字段的 NULL 处理。比如 SUM() 遇到全 NULL 返回 NULL，而 COALESCE(SUM(x), 0) 才符合业务预期；关联时用 LEFT JOIN 产生的 NULL 行，也要检查是否该计入分母（如计算人均订单数时，是否包含零订单用户）。
