多对多关联导致金额统计翻倍是JOIN生成重复行后SUM在物理层累加的必然结果；必须用子查询预聚合切断膨胀链，而非在SUM中加DISTINCT或调参数。
多对多关联导致金额统计翻倍，不是SQL写错了，是JOIN生成重复行后SUM在物理层累加的必然结果；必须切断膨胀链，而不是在SUM()里加DISTINCT或调参数。
为什么SUM()会翻倍——先看执行计划里的rows_examined
一对多或多对多JOIN后，主表一行会被复制N次（N=匹配的从表行数），SUM()就真对这N行逐行加一遍。典型表现：总金额是预期值的整数倍，且倍数≈单主键平均匹配行数。
- 用
EXPLAIN看执行计划，若某步rows_examined远大于左表实际行数，基本可锁定膨胀源 -
COUNT(*)在同样JOIN下也会虚高，别以为只有SUM()受影响 - 验证是否已膨胀：运行
SELECT main_id, COUNT(*) FROM main_table m LEFT JOIN detail_table d ON m.id = d.main_id GROUP BY m.id，看单个main_id是否对应多行
用子查询预聚合切断膨胀链
核心动作是让从表先按业务主键压缩成一行，再和主表关联。这样每行主表只对应1行聚合值，SUM()、COUNT()不再有重复行可加。
- 子查询必须
GROUP BY从表的外键（如order_id、user_id），漏掉这步等于白做 - 外层
ON条件字段必须和子查询GROUP BY字段严格一致，类型也要匹配（比如都是BIGINT，避免VARCHAR隐式转换） - 用
LEFT JOIN时，记得用COALESCE(t.total_amount, 0)处理NULL，否则没明细的主表记录会显示NULL而非0 - 过滤条件（如只算
status = 'paid'的订单）必须写在子查询内部，不能挪到外层WHERE，否则LEFT JOIN退化为INNER JOIN
用SUM() OVER (PARTITION BY ...)避免行数变化
当你需要同时返回明细行和汇总值（比如每行显示“本订单总金额”），窗口函数比传统JOIN更干净——它不改变行数，只把聚合值广播到每行。
-
PARTITION BY必须选主表唯一标识字段（如order_id），确保每个主表单位只计算一次 - 错误写法：
COUNT(DISTINCT oi.product_id) OVER (PARTITION BY o.order_id)→ 仍会因明细行重复导致计数偏高 - 正确做法：若需聚合的是从表字段，先在子查询/CTE里完成从表侧聚合，再和主表
LEFT JOIN - MySQL 5.7及以前不支持
OVER，必须改用相关子查询或预聚合
最容易被忽略的是：问题根源不在SUM()函数本身，而在JOIN引入的隐式重复行。盯着聚合函数调参不如先确认GROUP BY字段和ON条件是否对齐，以及COALESCE()是否覆盖了所有NULL场景。
