left join后sum翻倍是因为一对多关系导致主表行被复制n次参与聚合；正确做法是先对子表按关联键预聚合（如select user_id, sum(amount) from orders group by user_id），再与主表join。
为什么LEFT JOIN后SUM结果翻倍了
因为主表一行关联到子表N行，JOIN会复制出N行参与后续聚合——SUM、COUNT等函数自然就放大N倍。这不是数据库bug，是关系代数的必然结果。
常见现象：查“每个用户的订单总金额”，users LEFT JOIN orders 后直接 SUM(orders.amount)，数值比实际高几倍。本质是没控制聚合粒度，让明细行直接进了聚合计算。
- 先确认是否真是一对多：用
COUNT(*)+GROUP BY users.id看每用户关联了多少订单行 - 若只需汇总值（如总金额、订单数），别在JOIN后直接聚合，改用子查询提前算好
- 若还需展示明细字段（如最新订单时间），就得用窗口函数或LATERAL，不能靠子查询一锅端
用子查询预聚合替代JOIN后聚合
把子表按关联键先聚一次，再和主表JOIN，能彻底避开膨胀问题。关键是子查询必须返回唯一键+聚合结果，且不带歧义字段。
例如统计每个用户订单总额：
SELECT u.id, u.name, COALESCE(t.total_amount, 0) AS total_amount FROM users u LEFT JOIN ( SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id ) t ON u.id = t.user_id;
- 子查询里
GROUP BY user_id保证每行唯一，不会导致外层JOIN重复 -
COALESCE(t.total_amount, 0)把无订单用户的NULL转为0，避免前端处理异常 - 子查询别名
t必须写，否则MySQL报错Error Code: 1248. Every derived table must have its own alias - 如果子表要加条件（如只算已支付订单），必须写在子查询内部，不能丢到外层WHERE里
子查询预聚合的性能与索引要点
子查询本身不慢，慢的是没走索引或重复执行。尤其当子查询被当作相关子查询（correlated subquery）时，可能对主表每行都执行一次。
- 确保子查询中的
GROUP BY字段有索引，比如orders(user_id)单列索引足够 - 避免在子查询里用函数或表达式做分组，如
GROUP BY YEAR(create_time)会让索引失效 - MySQL 5.7及更早版本对子查询优化弱，可考虑物化为派生表（即上面写的写法），比
WHERE id IN (SELECT...)更稳 - PostgreSQL中可直接用
LATERAL替代，语义更清晰，但MySQL不支持
什么时候不该用子查询预聚合
不是所有一对多场景都适合子查询。它解决的是“只要聚合值”的需求，一旦需要原明细中的非分组字段（比如最新订单的status或created_at），子查询就力不从心。
- 要取“每个用户的最新一笔订单状态”：子查询无法同时返回
MAX(created_at)和对应那行的status，得用窗口函数 - 要拼接“每个用户的所有商品名”：子查询只能给总数，拼字符串得靠
STRING_AGG或GROUP_CONCAT配合GROUP BY - 子查询嵌套过深（三层以上）会显著增加优化器负担，此时CTE可能更易读，但注意CTE在MySQL中只是语法糖，不物化
最易被忽略的一点：子查询预聚合后，外层不能再对子表字段做条件过滤（比如想筛“订单总额 > 1000 的用户”），必须把条件移到子查询里或用 HAVING，否则逻辑就错了。
