JOIN后SUM结果重复是执行顺序导致的必然现象：先JOIN生成膨胀结果集，再SUM累加重复行；修复需从数据结构层面切断“主表一行变多行”链条，如用子查询预聚合或SUM() OVER。
JOIN后SUM结果重复不是SQL写错了，是执行顺序导致的必然现象：JOIN先生成膨胀结果集，SUM再对重复行累加。修复必须从数据结构层面切断“主表一行变多行”的链条，不能靠改聚合函数参数硬凑。
为什么SUM()在JOIN后一定会翻倍
数据库执行顺序是：FROM → JOIN → WHERE → GROUP BY → SELECT → SUM()。哪怕你只写SUM(o.amount)，系统也得先把orders和order_items完整JOIN出来——一个订单匹配3条明细，订单字段就复制3次，SUM()自然把同一笔金额加3遍。
- 典型表现：查出的总金额是报表或子查询结果的整数倍（2倍、3倍），且倍数恰好等于关联表中该主键的平均匹配行数
- 执行计划里
rows_examined远大于左表行数，基本可确认是JOIN膨胀 -
SUM(DISTINCT amount)完全无效：它去重的是数值，不是行；两笔不同订单碰巧都是100元，就会被当成一个值计算
用子查询预聚合是最稳妥的修复方式
核心动作是让明细表先按业务主键压缩成一行，再和主表关联。这样每行主表只对应1行聚合值，SUM()不再有重复行可加。
- 子查询必须
GROUP BY明细表的外键（如order_id、user_id），漏掉这步等于白做 - JOIN条件字段必须和子查询
GROUP BY字段严格一致，类型也要匹配（比如都是INT，避免VARCHAR隐式转换） - 用
LEFT JOIN时，记得用COALESCE(ord.total_amount, 0)处理NULL，否则没明细的订单会显示NULL而非0
SELECT o.id, o.order_date, COALESCE(i.total_price, 0) AS total_price FROM orders o LEFT JOIN ( SELECT order_id, SUM(price) AS total_price FROM order_items GROUP BY order_id ) i ON o.id = i.order_id;
用SUM() OVER避免行膨胀，但有适用边界
当你要同时返回明细行和汇总值（比如每行显示“本订单总金额”），SUM() OVER (PARTITION BY order_id)比传统JOIN更干净——它不改变行数，只把聚合值广播到每行。
-
PARTITION BY字段必须是主表唯一标识（如order_id），否则仍会算错 - 不能用它聚合右表字段（如
COUNT(DISTINCT oi.product_id) OVER），因为窗口函数无法自动去重已膨胀的行 - 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;
WHERE过滤右表字段会让LEFT JOIN悄悄变成INNER JOIN
这是线上事故高发区。想查“已支付订单的用户总金额”，如果写WHERE o.status = 'paid'，所有没订单或订单未支付的用户都会被过滤掉，LEFT JOIN形同虚设。
- 正确做法是把过滤条件移到
ON子句：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 如果右表本身存在重复主键（比如
user_id在orders表里出现多次），先用ROW_NUMBER()或GROUP BY清洗，别指望JOIN逻辑能兜底 - 检查约束：
SHOW CREATE TABLE orders，确认user_id是否有UNIQUE或PRIMARY KEY，没有就说明数据模型本身有问题
真正容易被忽略的点是：问题不在SUM()函数，而在你是否看清了JOIN后实际产出的中间结果集结构。跑一遍SELECT u.id, COUNT(*) OVER (PARTITION BY u.id)，比调十次SUM()参数都管用。
