窗口累计值“重复”主因是ORDER BY列存在重复值导致RANGE帧误将多行视为同一窗口，或漏写PARTITION BY造成跨组累加，或NULL排序未显式声明引发序号漂移。
ORDER BY列存在重复值导致窗口边界模糊
累计金额“重复”不是函数算错了，而是数据库把多个排序值相同的行当成了同一窗口帧处理。比如 ORDER BY created_at 下有 5 笔订单同为 '2026-09-25'，默认帧 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 仍按物理顺序逐行累加；但若误用 RANGE，这 5 行会被打包进一个窗口，导致第 1 行和第 5 行的累计值完全一样——因为它们共享同一“当前行位置”的上界。
这种重复现象在 PostgreSQL 和 SQL Server 中更明显，MySQL 8.0+ 对 RANGE 支持有限，但一旦用了，行为同样不可控。
- 检查是否显式写了
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW—— 大多数场景不该用RANGE - 用
SELECT created_at, COUNT(*) FROM orders GROUP BY created_at HAVING COUNT(*) > 1快速定位重复时间点 - 别依赖数据库隐式补序：即使主键是
id，优化器也可能在 JOIN 或 WHERE 后重排
PARTITION BY漏写或粒度错位造成跨组污染
看起来是“重复”，其实是不同业务单元的累计值被混在一起了。例如想算每个用户的消费累计，却只写了 SUM(amount) OVER (ORDER BY created_at)，没加 PARTITION BY user_id。结果就是用户 A 的第 3 笔订单，其累计值里可能包含了用户 B 前 2 笔、用户 C 前 5 笔……所有比它 created_at 早的记录。最终多个人在同一时间点显示出相同累计值，纯属巧合叠加。
- 确认业务单位是否唯一对应
PARTITION BY字段（如user_id、product_id） - 避免用表达式分区，如
PARTITION BY YEAR(created_at)—— 每次计算都触发函数，且无法利用索引 - 如果必须按月分组，先在子查询中生成
year_month字段再分区，比实时计算更稳
空值参与排序引发行序漂移
NULL 在 ORDER BY 中的默认位置因数据库而异：PostgreSQL 和 Oracle 默认 NULLS LAST，MySQL 8.0+ 和 SQL Server 默认 NULLS FIRST。如果你的 created_at 允许为空，又没显式声明 NULLS LAST，那一批 NULL 订单就会被挤到结果集开头或结尾，打乱真实业务时序。更麻烦的是，这些 NULL 行之间也无序，数据库可能每次执行都换顺序，导致累计值忽高忽低甚至重复。
- 始终显式写
ORDER BY created_at NULLS LAST（或NULLS FIRST，按业务定） - 对关键排序字段加
NOT NULL约束，比运行时处理更可靠 - 若业务允许，用
COALESCE(created_at, '1970-01-01')替代裸NULL，但注意会扭曲语义
误用全表窗口而非分组窗口
最隐蔽的一种：你写了 PARTITION BY user_id，但 ORDER BY 用的是全局时间戳（如 created_at），而不同用户的订单时间高度重合。结果就是多个用户在同一天的累计值“撞车”——比如用户 A 和用户 B 都在 '2026-09-25' 下了第一单，他们的 cum_amount 都是各自首笔金额，看起来数值相同，实则是独立计算的巧合。这不是 bug，但容易被当成异常。
- 验证方式：加一列
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at, id)，看是否每组内序号连续且从 1 开始 - 若需强调“首次下单日”，应提前用子查询提取每个用户的
MIN(created_at)，再关联，而不是靠窗口函数硬扛 - 真正难的不是让数字不重复，而是确认“重复”是否违反业务定义——有时相同值恰恰说明逻辑正确
