一对多JOIN后SUM失真因JOIN在聚合前执行导致主表行被复制，SUM重复累加；解法一是子查询预聚合（需GROUP BY、别名、过滤条件内置、COALESCE防NULL），二是窗口函数SUM() OVER(PARTITION BY)用于带明细场景；须验证连接字段唯一性、子查询必带GROUP BY、NULL必须转0。
为什么一对多JOIN后SUM会失真
因为JOIN在聚合前执行，主表一行被复制成N行（N = 子表匹配行数），SUM就真的一行行加了N遍。比如1个用户有3笔订单，LEFT JOIN orders后该用户数据变成3行，SUM(orders.amount)就把同一组订单金额加了3次——数值翻倍但SQL不报错，执行计划里rows_examined却可能暴涨10倍。
用子查询预聚合切断行复制链
这是最通用、兼容性最好的解法，MySQL 5.7+、PostgreSQL、SQL Server 都能跑。核心是不让明细数据直接进最终聚合，先各自按关联键压缩成单行。
- 子查询必须带
GROUP BY，且字段要和外层ON条件严格一致，比如子查询按user_id分组，外层就得写ON u.id = t.user_id - 子查询必须起别名，否则MySQL报
Error Code: 1248 - 过滤条件（如只算
status = 'paid'）必须写在子查询内部，不能丢到外层WHERE——否则膨胀已发生，子查询也救不回来 - 用
COALESCE(t.total_amount, 0)把NULL转成0，避免前端空值异常
示例：
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 WHERE status = 'paid' GROUP BY user_id ) t ON u.id = t.user_id;
SUM() OVER(PARTITION BY)适合带明细行的场景
当你既要展示每条明细（比如每笔订单项），又要显示“本订单总金额”，窗口函数比预聚合更干净——它不改变行数，也不引入重复。
-
PARTITION BY必须选主表唯一字段（如order_id），否则仍会失真 - 不能用
ORDER BY在窗口定义里凑累积和，除非业务真需要，否则易引发性能或语义问题 - 如果要聚合的是从表字段（如
COUNT(DISTINCT oi.product_id)），SUM() OVER无能为力，必须退回子查询预聚合 - MySQL 8.0+、PostgreSQL 9.4+支持；MySQL 5.7及以前不支持
OVER，得换方案
示例：
SELECT oi.order_id, oi.price,
SUM(oi.price) OVER (PARTITION BY oi.order_id) AS order_total
FROM order_items oi;
最容易被忽略的三个细节
第一，没检查连接字段是否真唯一——跑一遍SELECT uid, COUNT(*) FROM orders GROUP BY uid HAVING COUNT(*) > 1，比调SQL快得多；第二，预聚合子查询漏了GROUP BY，等于白写；第三，LEFT JOIN未匹配时，聚合字段是NULL，SUM(NULL)返回NULL而非0，前端一碰就崩，COALESCE不是可选项，是必选项。
