SUM() OVER() 能做不间断累计是因为它是窗口函数，可在保留原行粒度前提下按 ORDER BY 指定顺序滑动累加；普通 SUM() 是聚合函数，会压缩行数、丢失明细。
为什么 SUM() OVER() 能做不间断累计，而普通 SUM() 不行
普通 SUM() 是聚合函数，一用就“收编”整组，丢失原始行粒度；SUM() OVER() 是窗口函数，它在不打乱原有行顺序和数量的前提下，按指定规则滑动累加。关键不是“能不能”，而是“在哪一维上累计”——你得明确告诉它排序依据，否则结果不可靠甚至报错。
常见错误现象：SELECT id, val, SUM(val) OVER() FROM t 看似能跑，但没 ORDER BY 的话，数据库可能任意排序，每次执行结果都可能不同；更糟的是某些版本（如旧版 MySQL）直接报错 Window 'w' lacks an ORDER BY clause。
- 必须搭配
ORDER BY子句（写在OVER()里），哪怕只是按主键排 - 如果业务要求“按时间先后累计”，
ORDER BY create_time比ORDER BY id更语义准确 - 重复时间戳？加个二级排序：
ORDER BY create_time, id避免非确定性
SUM() OVER() 分组内累计的写法和陷阱
所谓“分组求和”，实际是“每组内部独立累计”，比如每个用户各自的订单金额累加。这时候要用 PARTITION BY 切分窗口，但很多人漏掉 ORDER BY，导致组内结果仍是无序累计。
使用场景：用户行为流水、商品日销量、设备每小时上报值等需“分主体+按时序累计”的数据。
-
PARTITION BY user_id ORDER BY create_time才是正确姿势；只写PARTITION BY user_id会触发警告或返回随机累计值 - MySQL 8.0+、PostgreSQL、SQL Server 都支持；SQLite 3.25+ 支持，但旧版不支持窗口函数
- 性能影响：大表上
ORDER BY字段最好有索引，否则排序开销明显
示例：
SELECT user_id, create_time, amount,
SUM(amount) OVER(PARTITION BY user_id ORDER BY create_time) AS cum_amount
FROM orders;
如何避免累计值“跳变”或“重置错误”
累计值突降、归零、或跨组污染，通常是因为 ORDER BY 值重复且未去重/未补序，或者 PARTITION BY 条件写错。例如用 status 代替 user_id 分组，结果把不同用户的记录混在一起累计。
容易踩的坑：
- NULL 值在
ORDER BY中默认排最前（MySQL）或最后（PostgreSQL），导致首行累计异常；显式写ORDER BY create_time NULLS LAST（PostgreSQL）或用COALESCE(create_time, '1970-01-01')（MySQL）统一处理 - 时间字段精度不一致（比如有的带毫秒，有的只有秒），造成逻辑上“同一时刻”被拆成多行排序，累计断层
- 误把过滤条件写在
WHERE之后却忘了它会影响窗口输入行数——想算“已支付订单累计”，别在WHERE status = 'paid'后直接套窗口，否则未支付的行根本进不来计算范围
替代方案对比：自连接 vs 变量 vs SUM() OVER()
老式写法如 MySQL 用户变量（@sum := @sum + val）或自连接 JOIN，在大多数现代场景下已被淘汰。变量方式在 8.0+ 默认禁用，且不保证执行顺序；自连接复杂、慢、难维护。
真正需要关注的是兼容性边界：
- PostgreSQL 和 SQL Server 对窗口函数支持最稳，语法一致
- MySQL 8.0+ 支持完整语法，但 5.7 及以前只能绕路（比如用存储过程或应用层累计）
- 如果目标库是 Hive 或 Spark SQL，
SUM() OVER()也支持，但注意ORDER BY必须存在，且大数据量时PARTITION BY字段倾斜会导致 reducer 崩溃
一句话：只要数据库版本够新，SUM() OVER(PARTITION BY ... ORDER BY ...) 就是最直接、最可读、最不易出错的解法——前提是，你真把 ORDER BY 写对了，而且它真的能唯一确定顺序。
