在SQL中如何用SUM OVER UNBOUNDED PRECEDING实现累加-SQL-PHP中文网

sum() over (order by ... rows between unbounded preceding and current row)是跨数据库最稳妥的累计求和写法：必须显式指定order by和rows帧，否则语义不明确或报错；partition by须置于order by前；重复排序值需加唯一列保障稳定性。

在sql中如何用sum over unbounded preceding实现累加

什么是 `SUM() OVER (ORDER BY ... ROWS UNBOUNDED PRECEDING)`

这不是一个“功能开关”，而是一条必须写全的窗口函数语法。漏掉 ORDER BY 会报错或结果不可控，ROWS 关键字也不能省——有些数据库（如 PostgreSQL）允许省略，但 MySQL 8.0+ 和 SQL Server 强制要求显式声明行模式，否则默认行为可能不是你想要的累加。

核心逻辑是：按指定列排序后，对当前行及之前所有行的某列求和。它不依赖自连接或变量，天然支持并发、可重复读。

ORDER BY 必须存在，且列要有确定性（避免相同值导致累加顺序漂移）
如果业务上需要“按时间累加但同秒有多条”，建议补上 ORDER BY created_at, id 防止非预期排序
UNBOUNDED PRECEDING 表示从分区第一行开始，到当前行为止；不能写成 UNBOUNDED FOLLOWING 或漏掉 PRECEDING

MySQL 8.0+ 中最简可用写法

MySQL 对窗口函数支持较晚，早期版本（ERROR 1064。确认版本后，以下是最小可运行模板：

SELECT
  id,
  amount,
  SUM(amount) OVER (ORDER BY id ROWS UNBOUNDED PRECEDING) AS running_total
FROM orders;

注意点：

别用 ORDER BY created_at DESC 想实现“倒序累加”——那其实是从最新一条开始往下加，不符合常规业务语义
如果 id 不连续或有空缺，不影响累加逻辑，窗口函数只看排序位置，不看数值间隔
字段别名（如 running_total）不能在 WHERE 或 HAVING 中引用，得用子查询或 CTE 包一层

常见错误：为什么累加结果全是 NULL 或单值？

典型现象是整列 running_total 都是 NULL，或所有行值都一样。大概率是下面几个原因：

源数据中 amount 字段本身为 NULL —— SUM() 遇到 NULL 会跳过，但如果全为 NULL，结果就是 NULL；用 COALESCE(amount, 0) 预处理
误写了 PARTITION BY 却没意识到分区重置逻辑，比如 SUM(...) OVER (PARTITION BY status ORDER BY id ...) 导致每个状态内重新累加
排序字段含大量重复值且无次级排序，数据库自由选择顺序，导致每次执行结果不一致（尤其在没有主键参与 ORDER BY 时）
用了 RANGE UNBOUNDED PRECEDING 而非 ROWS，在某些数据库中（如 PostgreSQL），RANGE 会对相同排序值做“合并累加”，行为更难预测