必须先用子查询或CTE对明细表按主键预聚合，再JOIN主表；否则一对多关联会导致SUM、COUNT因数据行膨胀而翻倍，这是数据逻辑错误而非写法问题。
必须先用子查询或CTE把聚合结果“压成一行/主键”，再拿这个结果集去JOIN，否则一对多关联会直接让SUM、COUNT翻倍——这不是写法问题，是数据逻辑错误。
为什么不能直接在GROUP BY后JOIN明细表
JOIN发生在聚合之前，数据库不会自动去重。比如一个用户有3笔订单、2个标签，LEFT JOIN orders + LEFT JOIN tags 会生成6行，后续SUM(order_amount)就在6行上算，不是按用户维度算。
- 现象：金额比实际高2–5倍，
COUNT(*)远大于COUNT(DISTINCT order_id) -
GROUP BY user_id救不回来——重复行已在JOIN阶段固化 - WHERE里加过滤（如
status = 'paid'）若放在外层，会漏掉无匹配记录的用户
用子查询实现聚合后再JOIN（MySQL/PostgreSQL通用）
子查询是兼容性最好、执行计划最可控的方式，关键点在于“主键对齐”和“别名强制”。
- 子查询必须有别名，例如
(SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id) AS o，否则报错Every derived table must have its own alias -
ON条件必须严格用聚合键对齐，如u.user_id = o.user_id，不能写成u.id = o.user_id - 聚合字段类型要一致，比如
user_id INT和user_id VARCHAR直接JOIN会报operator does not exist - 记得给聚合子查询的关联字段建索引（如
orders(user_id)），否则JOIN退化为全表扫描
用CTE提升可读性（PostgreSQL/MySQL 8.0+）
CTE不改变执行逻辑，但能把多张明细表各自的聚合逻辑拆开写，避免嵌套过深。
WITH user_orders AS ( SELECT user_id, COUNT(*) AS order_cnt, SUM(amount) AS total FROM orders WHERE order_date >= CURRENT_DATE - INTERVAL '30 days' GROUP BY user_id ), user_tags AS ( SELECT user_id, STRING_AGG(tag_name, ',') AS tag_list FROM user_tags ut JOIN tags t ON ut.tag_id = t.id GROUP BY user_id ) SELECT u.name, o.order_cnt, o.total, t.tag_list FROM users u LEFT JOIN user_orders o ON u.user_id = o.user_id LEFT JOIN user_tags t ON u.user_id = t.user_id;
- 每段CTE只负责一张表的聚合，职责清晰
- 仍需确保每个CTE的
GROUP BY字段和SELECT中非聚合字段完全一致，否则MySQL 8.0+或PostgreSQL会报错 - CTE不是物化视图，多次引用同一CTE可能重复计算，大数据量时注意性能
更新目标表时怎么用聚合结果（UPDATE + JOIN场景）
UPDATE语句不能直接写GROUP BY，所有聚合必须前置为子查询，并通过JOIN或FROM引入。
- MySQL必须用
UPDATE ... JOIN (subquery) AS agg，且子查询别名不可省 - PostgreSQL要用
UPDATE ... FROM (subquery) AS agg，并在WHERE中显式写u.id = agg.user_id - 子查询若对同一主键返回多行（如没加
GROUP BY），PostgreSQL会报more than one row returned by a subquery - 建议在SET里用
COALESCE(agg.total, 0)，避免NULL导致业务逻辑异常
最容易被忽略的是：聚合子查询里的过滤条件（如时间范围、状态）一旦漏写，或者错放到外层WHERE，结果就不可信；而JOIN时字段类型不一致、缺少索引、别名缺失这些细节，往往在数据量上涨后才暴露性能断崖。
