直接在JOIN后用SUM() OVER()会出错，因JOIN导致主表记录重复，使窗口函数在重复行上重复累加；正确做法是先在子查询/CTE中对干净数据开窗，再JOIN，或先GROUP BY聚合再开窗。
为什么直接在 JOIN 后用 SUM() OVER() 会出错
常见错误是先 JOIN 多表再套 SUM() OVER()，结果累计值翻倍甚至爆炸。根本原因是 JOIN 导致主表记录被“撑开”——比如订单表和订单明细表 LEFT JOIN 后，一个订单对应多行明细，SUM() OVER() 就会在重复的订单行上反复累加同一笔金额。
正确做法是：先在明细层做窗口计算，再 JOIN 汇总结果；或先聚合明细（如按订单汇总金额），再 JOIN 主表。
- JOIN 前没去重或没聚合，
SUM() OVER()的输入行数已失真 - ORDER BY 子句若漏写或逻辑错（比如用非时间字段排序），累计顺序就乱
- 如果 JOIN 条件含 NULL 或隐式类型转换，可能意外丢行，让累计断层
用子查询隔离窗口计算再 JOIN
把窗口函数放在子查询或 CTE 中独立执行，确保它只作用于干净、无重复的源数据集，再通过主键 JOIN 回业务表。这是最可控的方式。
例如：要给每个用户按登录时间算累计登录次数，并关联用户昵称：
WITH login_cum AS (
SELECT
user_id,
login_time,
COUNT(*) OVER (PARTITION BY user_id ORDER BY login_time) AS cum_login_cnt
FROM user_logins
)
SELECT
l.user_id,
u.nickname,
l.login_time,
l.cum_login_cnt
FROM login_cum l
JOIN users u ON l.user_id = u.id;
- 窗口函数只在
user_logins表内运行，不受users表影响 -
PARTITION BY user_id保证每人独立累计，不跨用户混算 - 若
login_time有重复，需加ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW显式控制范围
JOIN 后仍需累计？必须先 GROUP BY 再开窗
某些场景确实得先 JOIN（比如要显示订单+客户+产品名称），又需要按客户维度累计订单金额。这时不能直接对 JOIN 结果开窗，必须先 GROUP BY 聚合成客户级汇总行，再在其上开窗。
示例：按客户首次下单时间排序，累计其历史订单总金额：
WITH cust_order_sum AS (
SELECT
c.id AS cust_id,
c.name,
MIN(o.order_date) AS first_order_date,
SUM(o.amount) AS order_amount
FROM customers c
JOIN orders o ON c.id = o.cust_id
GROUP BY c.id, c.name
)
SELECT
cust_id,
name,
first_order_date,
SUM(order_amount) OVER (
ORDER BY first_order_date, cust_id
) AS cum_amount_by_first_order
FROM cust_order_sum;
- GROUP BY 是必须步骤，否则
SUM() OVER()会基于原始 JOIN 行数计算，结果虚高 -
ORDER BY first_order_date, cust_id防止时间相同时排序不稳定，导致累计值抖动 - 注意：这里累计的是每个客户的
order_amount（已聚合），不是单笔订单
性能与兼容性要注意的点
窗口函数 + JOIN 的组合容易触发全表扫描或临时表膨胀，尤其在大数据量时。不同数据库优化能力差异大。
- PostgreSQL 和 SQL Server 对
OVER()推送下推支持较好；MySQL 8.0+ 可以，但旧版不支持窗口函数 - 如果
PARTITION BY字段没有索引，且数据量大，SUM() OVER()可能变慢十倍以上 - 避免在 JOIN 条件中用函数（如
UPPER(c.name) = UPPER(o.customer_name)），这会让窗口计算前无法走索引 - 当累计字段涉及 DECIMAL 运算，注意各数据库对精度的处理差异，比如 PostgreSQL 默认保留小数位，MySQL 可能截断
真正难的不是语法，是想清楚“累计对象是谁”——是原始明细行？还是某一层聚合后的逻辑行？一旦混淆，后面所有结果都不可信。
