LEFT JOIN后SUM翻倍是因为一对多关联导致主表一行被复制为多行，使SUM重复累加；正确解法是先对多端表按关联键预聚合再JOIN，或用SUM() OVER(PARTITION BY 主表唯一键)避免行级膨胀。
为什么LEFT JOIN后SUM结果会翻倍
因为1对多关联时，主表一行被扩展成多行，再用SUM()聚合，相当于把主表字段重复累加了多次。比如订单表1条记录关联3条订单项，SUM(order_amount)就会算3遍这个金额。
典型现象：查出的总金额、计数明显高于实际值，且和子查询或报表数据对不上。
- 不是数据本身重复，是JOIN逻辑导致行膨胀
-
COUNT(*)、SUM()、AVG()等聚合函数都会受此影响 - 用
DISTINCT在聚合里包字段（如SUM(DISTINCT order_id)）完全不可靠，会漏加或错加
SUM OVER配合PARTITION BY避免翻倍
核心思路：先按主表粒度算好聚合值，再把它“广播”到每行，不参与JOIN后的行级膨胀。用窗口函数SUM() OVER(PARTITION BY ...)替代普通SUM()即可。
关键点是PARTITION BY必须选主表唯一标识字段（如order_id），确保每个主表单位只计算一次。
SELECT o.order_id, o.order_date, o.customer_id, -- 正确：每个order_id只算一次总金额 SUM(o.amount) OVER (PARTITION BY o.order_id) AS total_order_amount, -- 错误：直接SUM会翻倍 -- SUM(o.amount) AS bad_total FROM orders o LEFT JOIN order_items oi ON o.order_id = oi.order_id;
- 窗口函数在JOIN之后执行，但
PARTITION BY让它按逻辑分组独立求和 - 只要
PARTITION BY字段在主表中唯一，结果就和主表行数一致 - 不能用
ORDER BY在窗口定义里（除非真需要累积和），否则可能影响性能或语义
什么时候不能只靠SUM OVER
当你要聚合的是从关联表来的字段（比如要统计每个订单有多少种商品），SUM() OVER仍会因行数膨胀出错——因为窗口函数无法自动去重。
此时必须先在子查询/CTE里完成关联表侧的聚合，再和主表JOIN。
- 错误写法：
COUNT(DISTINCT oi.product_id) OVER (PARTITION BY o.order_id)→ 仍会重复计数 - 正确做法：用CTE先聚合
order_items，再LEFT JOIN回orders - 如果关联表有NULL值，
COUNT()会忽略，但COUNT(*)不会，注意语义差异
MySQL 8.0+ 和 PostgreSQL 的兼容性提醒
窗口函数在MySQL 8.0+、PostgreSQL 9.4+、SQL Server 2005+都支持，但低版本MySQL（5.7及以前）不支持OVER，必须改用相关子查询或JOIN聚合。
- MySQL 5.7替代方案示例：
(SELECT SUM(amount) FROM orders o2 WHERE o2.order_id = o.order_id) - PostgreSQL中
SUM() OVER默认行为和MySQL一致，无需额外配置 - Oracle用户注意：
SUM() OVER语法相同，但空值处理策略略有不同，建议显式用NVL()或COALESCE()
真正容易被忽略的是：窗口函数解决的是“聚合值重复”，不是“数据重复”。如果业务上真需要去重后的明细行，还得结合DISTINCT或GROUP BY，不能只依赖OVER。
