SQL中SUM OVER函数实现累加求和的方法

窗口函数在SQL中的应用非常广泛，但很多人一看到SUM(OVER)这种写法，第一反应就是懵。别急，咱们今天就把这事儿彻底讲清楚。

什么是SUM(OVER)？它不是独立函数，而是窗口函数用法

严格来说，SUM(OVER)并不是一个独立的函数——它本质上是在SUM()函数后面加上OVER子句，组合成窗口函数。直接写SUM(OVER ...)肯定会报错，正确的写法是SUM(column_name) OVER (...)。

一个很常见的错误现象是，报错信息里出现“ERROR: syntax error at or near 'OVER'”，这往往是因为括号里漏了求和字段，或者把OVER当成了SUM的参数。来看几个例子：

• SUM(sales) OVER (ORDER BY date) ✅ 正确写法：对sales字段按日期累加
• SUM OVER (ORDER BY date) ❌ 错误：缺少了被聚合的列
• SUM(sales OVER (ORDER BY date)) ❌ 错误：OVER不能放在括号里当参数

如何写累加（运行总计）？关键看ORDER BY和PARTITION BY

累加的核心，在于定义清楚“按什么顺序加”和“是否要分组重置”。如果不加ORDER BY，SUM() OVER()的结果就是全表的总和，每行都一样；只有加上ORDER BY，才会形成逐行累加的效果。

拿销售日报表来举例，要计算截至当日的累计销售额：

• SUM(amount) OVER (ORDER BY order_date) → 全局按日期递增累加
• SUM(amount) OVER (PARTITION BY region ORDER BY order_date) → 每个地区内独立累加
• 如果只写SUM(amount) OVER ()，结果每行显示的都是同一个值（全表总和），这可不是累加

这里有个细节需要注意：ORDER BY的列必须要有确定的排序，避免重复值导致累加结果不确定。必要时可以加上唯一键，比如写成ORDER BY order_date, id。

为什么结果和预期不符？检查空值、重复排序键和框架默认行为

写完了累加，结果看起来却不对？别急，90%的问题都出在以下三类情况：空值参与计算、排序键重复，以及没意识到默认框架是ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。

• 如果字段里有NULL，默认会被忽略，不影响累加。但如果想把NULL当成0处理，得先用COALESCE(amount, 0)转换一下。
• 如果ORDER BY的字段有重复值，比如多笔订单在同一个日期，数据库可能会随意打乱这些行的顺序，导致累加值出现跳跃或不稳定。
• 如果想改成只包含当前行和前一行，需要显式写成ROWS BETWEEN 1 PRECEDING AND CURRENT ROW，否则默认是从开头到当前行。

来看一个实际例子（PostgreSQL/MySQL 8.0+/SQL Server中都能用）：

SELECT   date,  sales,  SUM(sales) OVER (ORDER BY date, id) AS cumsumFROM daily_sales;

不同数据库对SUM(OVER)的支持差异有哪些？

语法看起来都差不多，但实际兼容性差别还挺大的。MySQL 5.7就不支持，必须升级到8.0以上；SQLite直到3.25版本才加入窗口函数支持；Oracle和SQL Server支持得比较早，但旧版本可能不支持ROWS框架子句。

• 确认版本：SELECT VERSION();（MySQL）、SELECT @@VERSION;（SQL Server）
• SQLite用户需要检查编译选项是否启用了ENABLE_WINDOW_FUNCTIONS
• 如果目标数据库不支持，替代方案是自连接或变量（比如MySQL 5.7的@cumsum := @cumsum + sales），但这种写法不可靠，也不是标准做法

真正麻烦的不是语法写不对，而是查了半天发现数据库压根不认OVER——动手前先验证环境，比调逻辑更重要。