先聚合再join能避免中间结果集爆炸和数据翻倍错误；需对每张明细表按业务主键独立预聚合，再left join并用coalesce显式补零，确保sum/count准确可信。
先聚合再JOIN能避免中间结果集爆炸
核心问题不是聚合慢，而是JOIN把数据“撑爆”了。比如10万用户 × 平均5笔订单 = 50万行中间结果，再GROUP BY；而先对orders按user_id聚合，可能只产出10万行（每用户一行），再JOIN users表，传输、内存、排序压力直接降一个数量级。EXPLAIN里看rows字段，如果从几十万骤降到几千，就是这个策略起效的明确信号。
先聚合再JOIN才能保证SUM/COUNT不翻倍
一对多关联时，数据库不做自动去重——1个用户有3笔订单、2个标签，LEFT JOIN后生成6行，SUM(amount)在这6行上加总，结果就是真实值的2–5倍。这不是性能问题，是数据错误。
-
COUNT(*)变成6，不是用户数1或订单数3 -
COUNT(DISTINCT order_id)能救数量，但金额类指标完全无法补救 - 必须对每张明细表独立预聚合：
SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id - 外层用
LEFT JOIN连聚合结果，ON条件严格对齐字段名和类型（如u.user_id = o.user_id，不能写成u.id = o.user_id）
聚合子查询里的WHERE必须下推，不能靠外层过滤
如果业务要求只统计VIP用户的订单，但聚合子查询没加WHERE u.level = 'vip'，而是把条件放在外层WHERE，就会先算出全部用户的汇总，再JOIN时才丢掉非VIP行——白算，且结果错。
- 正确做法：把筛选条件下推到子查询里，例如
SELECT user_id, SUM(amount) FROM orders WHERE status = 'PAID' GROUP BY user_id - 别在子查询里写
WHERE status = 'paid'，又在外层ON或WHERE里重复加一遍，会导致双重过滤漏数据 - 若需保全左表所有用户（包括无订单者），子查询不能带
WHERE过滤用户维度字段，否则COALESCE(o.total_amount, 0)也补不回空行
容易被忽略的NULL和零值处理
预聚合子查询默认只产出有数据的user_id，LEFT JOIN后若某用户无订单，对应字段就是NULL，不是0——前端展示为空、报表求和异常、甚至被WHERE意外过滤掉。
- 必须用
COALESCE(os.total_amount, 0)显式补零，不能依赖子查询自己返回全量用户 - 聚合字段含
NULL（如某用户所有amount都是NULL），SUM()返回NULL，JOIN时可能因ON u.user_id = t.user_id不匹配而丢行，需检查t.user_id是否NOT NULL，必要时加WHERE t.user_id IS NOT NULL - MySQL 8.0+ 推荐用CTE，PostgreSQL可用
LATERAL，结构更清晰；MySQL 5.7+用派生表也行，但注意别名作用域
COALESCE补零逻辑。
