累计求和报表在业务系统中几乎随处可见：销售团队需要查看每个客户从年初到当前的订单总额，财务人员要跟踪费用科目的逐月累计发生额，运营同学也会按天汇总活跃用户的累计增长曲线。常见的解决方式有两种，一是使用关联子查询，把当前行之前的所有记录做SUM聚合；二是引入游标，在程序里逐行累加。前者SQL写起来啰嗦，数据量稍大就会产生严重的性能问题；后者则把计算压力转移到了应用端，可读性也不高。实际上，主流关系型数据库从MySQL 8.0开始已经普遍支持窗口函数，其中SUM OVER正是处理累计求和最便捷的工具。它能在一行SQL中保留明细记录的同时追加累计值，让报表开发大幅简化。
先理解窗口函数与累计求和的基本语义
窗口函数和普通聚合函数最大的区别在于是否折叠行。比如SUM(amount)配合GROUP BY customer_id时，每个客户只返回一行汇总结果，明细数据被合并。而窗口函数不同，它不会减少结果集的行数，而是在每一行旁边增加一个计算列。拿累计求和来说，SUM(amount) OVER (ORDER BY order_date)会在每一行上计算从数据集中日期最早的一行到当前行的金额总和。这里OVER子句是窗口函数的核心，ORDER BY order_date定义了窗口内行的排序顺序，累计方向就由这个顺序决定。
如果不加ORDER BY，例如SUM(amount) OVER ()，窗口就是整个结果集，每一行都会得到同一个总量，也就是一个全局合计。如果加入PARTITION BY customer_id，则窗口会按客户分组，在每个客户内部独立做累计。比如SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date)，会先按客户分开，再按日期排序，每行的累计值只针对当前客户，不会跨客户累加。这种能力在生成按实体分组的累计报表时非常关键。
一个简单的示例如下：
SELECT
order_id,
customer_id,
order_date,
amount,
SUM(amount) OVER (ORDER BY order_date) AS cumulative_amount
FROM orders
ORDER BY order_date;
这里cumulative_amount就是全局累计金额，从最早的订单日期一直加到当前行。由于没有PARTITION BY，全部数据被视为一个分区。理解了这一层后，就可以根据实际业务增加分组条件。
实战：按客户和月份生成累计销售额报表
假设我们有一张订单表orders，核心字段包含customer_id、order_date和amount。业务端的要求是：在客户明细中按订单日期展示每一笔订单金额以及该客户截至当日的累计销售额。如果使用窗口函数，一条查询即可完成：
SELECT
customer_id,
order_date,
amount,
SUM(amount) OVER (
PARTITION BY customer_id
ORDER BY order_date
) AS cumulative_sales
FROM orders
ORDER BY customer_id, order_date;
这个写法里PARTITION BY customer_id先把数据按客户隔离，ORDER BY order_date保证窗口内按照日期递增。SUM(amount)在每一行都会计算从该客户最早一笔订单到当前行的金额合计。如果某天有多笔订单，单号顺序会按order_date相同而无法区分先后，这时候需要额外在ORDER BY中加入唯一字段，否则累计值在当天可能重复。这一点后面再详细说明。
如果报表粒度不是订单明细，而是按月汇总，那么可以先用子查询把每个客户每月的销售金额聚合成一行，再在外层使用窗口函数计算累计值。下面是MySQL环境下按月份累计的示例：
SELECT
customer_id,
order_month,
monthly_amount,
SUM(monthly_amount) OVER (
PARTITION BY customer_id
ORDER BY order_month
) AS cumulative_monthly_sales
FROM (
SELECT
customer_id,
DATE_FORMAT(order_date, '%Y-%m') AS order_month,
SUM(amount) AS monthly_amount
FROM orders
GROUP BY customer_id, DATE_FORMAT(order_date, '%Y-%m')
) t
ORDER BY customer_id, order_month;
子查询先把日期按月份归一化，并聚合得到monthly_amount。外层窗口函数在客户分组内按月份排序，逐月累加。这样即使订单表中有大量日明细，也能快速得到月累计报表。对于PostgreSQL，可以改用to_char(order_date, 'YYYY-MM')，Oracle可以使用TO_CHAR，思路完全一致。
重复排序字段引发的 ROWS 与 RANGE 行为差异
写累计求和报表时，一个很容易被忽略的细节是窗口函数的帧范围。在标准SQL中，ORDER BY存在时，默认的帧范围是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。这里RANGE的含义是基于排序键值的范围，而不是基于物理行。如果ORDER BY后面只有一个日期字段，并且同一天有多笔订单，那么同一天的所有行会被视为相同的排序键值，当前行的累计结果会包含全部同日的金额，而不是只累加到当前行为止。这会得到一个奇怪的现象：同一天的多行记录，累计销售额完全相同，都是当天结束后的总和。
还是以订单表为例，先看默认RANGE行为：
SELECT
order_date,
amount,
SUM(amount) OVER (ORDER BY order_date) AS range_cumulative,
SUM(amount) OVER (
ORDER BY order_date
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS row_cumulative
FROM orders
ORDER BY order_date, amount;
假设2025-01-05有三笔订单，金额分别是100、200、300。range_cumulative在该日期的三行都会显示包含当天全部600元的累计结果；而row_cumulative则会按照物理行逐行累加，第一行加100，第二行再加200，第三行再加300。如果你的业务要求每一行明细都体现准确的逐笔累计，就必须显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。如果你的业务只关心某一天的最终累计值，那么先按天聚合后再使用窗口函数会更清晰。
理解了ROWS和RANGE的区别后，还可以很方便地实现滚动窗口，比如查看每行日期最近7天的销售额总和：
SELECT
order_date,
amount,
SUM(amount) OVER (
ORDER BY order_date
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) AS last_7_days_sum
FROM orders
ORDER BY order_date;
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW表示从当前行往前数6行再加上当前行，一共7行，适合按行粒度做近7日滚动统计。如果数据日期存在间隔，最好先按日期聚合补齐日期序列，否则这里的“7天”实际是“最近7条记录”。这个细节在日报、周报类累计分析中经常被误解。
性能优化与常见错误排查
窗口函数虽然写起来简单，但底层仍然需要排序和扫描。对于百万级以上的订单表，ORDER BY字段最好建立索引，避免数据库在每次查询时进行临时排序。通常可以创建复合索引，例如CREATE INDEX idx_orders_customer_date ON orders (customer_id, order_date)，这样既能满足PARTITION BY customer_id的分组扫描，也能利用索引有序性完成窗口内排序。如果查询还包含WHERE过滤条件，索引设计需要结合过滤字段一起考虑。已经按日期分区的表，可以进一步减少扫描范围。
日常使用窗口函数时，有几个错误非常常见。第一个是在WHERE子句中直接引用窗口函数结果。例如有的同学会写WHERE cumulative_sales > 1000，但SQL执行顺序里WHERE先于窗口函数计算，这样的语句会直接报错。正确的做法是使用子查询或CTE，先完成窗口计算，再在外层过滤：
WITH tmp AS (
SELECT
customer_id,
order_date,
amount,
SUM(amount) OVER (
PARTITION BY customer_id
ORDER BY order_date
) AS cumulative_sales
FROM orders
)
SELECT *
FROM tmp
WHERE cumulative_sales > 1000;
第二个常见问题是混淆分组聚合和窗口函数。比如需要每个客户的月累计，如果直接写GROUP BY customer_id加SUM(amount) OVER (ORDER BY order_date)，结果会因为分组已经折叠了日期信息而变得没有意义。正确做法是先明确报表粒度，再决定在哪一层做窗口计算。第三是忽略NULL值对排序的影响，如果日期字段允许为空，空值可能被排在最前面或最后面，导致累计结果与预期不符。建议在ORDER BY中使用COALESCE(order_date, '1970-01-01')之类的兜底值，保证排序稳定。
最后，窗口函数在多数数据库中不能直接在UPDATE语句中更新目标表，因为同一查询中的目标表与窗口函数读取可能冲突。遇到这种场景时，可以先把计算结果写入临时表，再通过关联更新。总体来说，把SUM OVER的语义和限制理解清楚，累计求和报表的开发效率和运行性能都能得到明显提升。