SQL累计求和不能直接用SUM()，因它是聚合函数会压缩成单行；需用窗口函数SUM() OVER，关键要写全ORDER BY（确保有序）、窗口范围（默认UNBOUNDED PRECEDING TO CURRENT ROW）和PARTITION BY（分组时）。
SQL累计求和为什么不能直接用SUM()？
这里有个常见的误区：为什么想计算累计和时，直接写个 SUM() 行不通？原因在于，SUM() 作为聚合函数，它的“本职工作”是把多行数据压缩成一行汇总结果。一旦用了它，原始数据的行级结构就消失了，你看到的只是一个孤零零的总数。而累计求和的本质，恰恰要求我们保留每一行，并按照特定的顺序（比如时间先后）逐行累加。这种“既要看明细，又要看累计”的需求，正是窗口函数 SUM() OVER 大显身手的典型场景。
怎么写SUM OVER才能得到正确累计和？
掌握了窗口函数这个工具，接下来就是关键操作了。想让 SUM() OVER 乖乖输出正确的累计和，核心在于明确三要素：排序依据、窗口范围、是否分区。这三项缺一不可，任何一项写错或遗漏，结果都可能南辕北辙。
- 排序依据 (
ORDER BY)：这是累计的逻辑基础，必须存在且合理。比如按交易日期、记录ID升序排列，累计才有意义。没有它，累计就失去了方向。 - 窗口范围：默认情况下，范围是
UNBOUNDED PRECEDING TO CURRENT ROW，意味着从分区内的第一行一直累加到当前行。这个隐式规则一定要了然于心。 - 是否分区 (
PARTITION BY)：如果需要分组计算——例如，为每个用户单独累计其订单金额——就必须加上PARTITION BY user_id。否则，所有用户的数据就会混在一起计算，得到一个全局累计值。 - 一个细节提醒：尽量避免在
OVER子句里写了ORDER BY，又在查询的最外层写另一个ORDER BY。这有时会导致执行计划混乱或结果顺序出现意料之外的变化。
常见错误现象和排查点
理论清楚了，一到实战还是容易踩坑。最常见的两种现象是：“累计值每一行都一模一样”或者“累计值忽大忽小，跳变不连续”。别慌，问题基本都出在下面这几个地方：
- 忘了写
ORDER BY：数据没有明确的排序依据，窗口函数可能会按数据库物理存储的顺序处理，结果自然不可预测。 - 排序字段有重复值：比如多个订单发生在同一天，如果只按
order_date排序，那么所有同一天的订单行会共享同一个累计值，看起来就像“卡住”了。解决办法是在ORDER BY末尾补充一个唯一字段，例如ORDER BY order_date, order_id，确保每一行都有确定的顺序。 - 混淆
PARTITION BY和GROUP BY：误以为PARTITION BY会减少行数。其实它只定义窗口范围，不会聚合行。如果发现结果行数变少了，那很可能是误用了GROUP BY。 - 数据库版本兼容性：尤其在 MySQL 5.7 及更早版本中，直接使用
SUM() OVER会触发语法错误。那时需要借助用户变量来模拟累计，或者考虑升级到 MySQL 8.0 以上版本。
一个带业务含义的实操示例
光说不练假把式，来看一个具体的业务场景。假设我们有一张销售记录表 sales，包含销售ID、产品、金额和日期字段。现在需要按日期顺序，计算出截至每一天的累计销售额。
SELECT sale_id, product, amount, sale_date, SUM(amount) OVER (ORDER BY sale_date, sale_id) AS cum_amount FROM sales;
注意这个例子里的两个细节：首先，排序使用了 sale_date, sale_id 双字段，这巧妙地避免了同一天内多笔销售记录被合并累计的问题。其次，生成的累计列 cum_amount 是一个别名，它是在窗口函数计算完成后才产生的。这意味着，你不能在同一个查询的 WHERE 或 HA VING 子句中直接引用这个别名来过滤数据——这是由SQL语句的执行顺序决定的，也是新手容易忽略的一个点。
