先聚合再JOIN是为了避免一对多关联导致的聚合结果翻倍；需对每张明细表按业务主键独立预聚合（如user_id），再LEFT JOIN聚合结果，并用COALESCE显式补零，确保金额、数量准确可信。
先聚合再JOIN不是为了“更准确”，而是避免因一对多关联导致的聚合结果翻倍——不这么干，SUM、COUNT 就会错，不是慢的问题，是数据不可信。
为什么直接JOIN后GROUP BY会算错金额和数量
数据库只做行拼接，不做自动去重。一个用户有 3 笔订单、2 个标签，LEFT JOIN orders + LEFT JOIN tags 后，该用户数据会膨胀成 6 行。后续 SUM(amount) 是在这 6 行上加总，不是按用户维度算。
-
COUNT(*)变成 6，而不是 1（用户数）或 3（订单数） -
SUM(amount)被重复累加，结果可能是真实值的 2–5 倍 -
COUNT(DISTINCT order_id)虽能救数量，但金额类指标完全无法补救
怎么写才真正避免翻倍：每张明细表独立预聚合
核心是把每张一对多表，各自按业务主键（如 user_id）压缩成一行，再对齐连接。不是堆 JOIN，是分层收口。
- orders 表单独聚合：
SELECT user_id, SUM(amount) AS total_amount, COUNT(*) AS order_cnt FROM orders GROUP BY user_id - tags 表单独聚合：
SELECT user_id, STRING_AGG(tag_name, ',') AS tag_list FROM user_tags JOIN tags USING (tag_id) GROUP BY user_id - 外层用
LEFT JOIN连这两张聚合结果，ON 条件必须严格对齐字段名和类型，比如u.user_id = o.user_id，不能写成u.id = o.user_id - PostgreSQL 可用
LATERAL替代子查询，MySQL 8.0+ 推荐 CTE，结构更清晰
容易被忽略的 NULL 和零值处理
预聚合子查询默认只产出有数据的 user_id，LEFT JOIN 后若某用户无订单，对应字段就是 NULL，不是 0 —— 这会导致前端展示为空、报表求和异常、甚至被 WHERE 过滤掉。
- 必须用
COALESCE(os.total_amount, 0)显式补零，不能依赖聚合子查询自己包含全量用户 - 如果报表要求“所有用户”，但聚合子查询只筛了
WHERE created_at >= '2026-07-01'，就得靠 LEFT JOIN + COALESCE，而不是指望子查询返回空行 - 别在子查询里写
WHERE status = 'paid'，又在外层 WHERE 或 ON 里再加一遍，会导致双重过滤漏数据
真正难的不是 SQL 怎么写，而是业务语义能否提前固化：比如“活跃用户”定义变一次，所有预聚合子查询都得同步改，且要验证是否影响 NULL 补全逻辑。
