因为累计求和需保留每行并动态累加，窗口函数SUM() OVER(ORDER BY ...)天然支持有序滚动计算，而GROUP BY强制压缩行数、无法生成逐行累计值，硬用会导致逻辑错误或复杂低效的变通写法。
为什么SUM() OVER()比GROUP BY更合适做累计求和
因为累计求和本质是“到当前行为止的滚动加总”，不是按维度聚合——GROUP BY会压缩行数，而窗口函数保留原始行结构，每行都能算出自己的累计值。用GROUP BY硬凑，要么得自连接，要么得嵌套子查询，可读性和性能都差。
常见错误是写成：SUM(sales) OVER (PARTITION BY region)，这其实算的是每个区域的总销售额（静态聚合），不是累计值。关键在ORDER BY子句是否出现、是否搭配ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（默认行为，但显式写出更安全）。
-
ORDER BY order_date必须存在，否则窗口无序，累计结果不可预测 - 如果日期有重复，建议追加唯一字段如
ORDER BY order_date, order_id避免排序不稳定 - 不加
PARTITION BY就是全表累计；加了就按指定字段分组各自累计（比如按PARTITION BY region算各区域内部累计）
如何处理NULL值导致的累计中断
SUM()窗口函数本身对NULL是自动跳过的，但问题常出在ORDER BY字段为NULL时——这些行会被排到最前面或最后面（取决于数据库），导致累计值从第1行开始就不连续。例如订单日期为空的记录排在开头，SUM(sales) OVER (ORDER BY order_date)会先累加一堆NULL销售，结果首几行累计值为NULL。
- 显式过滤：
WHERE order_date IS NOT NULL（推荐，业务上通常也不该有无日期的销售） - 用
COALESCE(order_date, '1970-01-01')兜底（慎用，可能污染时间序列逻辑） - 检查执行计划，确认
ORDER BY字段有索引，否则排序开销大，尤其数据量大时
MySQL 8.0+与PostgreSQL中SUM窗口的实际写法差异
核心语法一致，但细节影响行为：
- MySQL 8.0+支持完整窗口定义，
SUM(sales) OVER (ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)可省略ROWS部分，默认即此行为 - PostgreSQL同样默认
ROWS范围，但若显式写RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，遇到相同order_date会把同天所有行当成一个逻辑单元累加（可能导致单日突增），而ROWS是逐行累加，更符合“动态”预期 - SQL Server需注意：如果没写
ORDER BY，SUM() OVER()会返回全表总和（非报错），容易误以为是累计
示例（通用写法）：
SELECT order_id, order_date, sales, SUM(sales) OVER (ORDER BY order_date, order_id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cum_sales FROM orders WHERE order_date IS NOT NULL;
累计销售额突然变小？检查是否误用了降序或重置逻辑
典型现象：某天累计值比前一天还小，或中间某行归零。大概率是ORDER BY方向写反了（用了DESC），或者误加了PARTITION BY且分区键变化频繁（比如按PARTITION BY status，状态变更导致重新计数）。
- 确认
ORDER BY是升序：ORDER BY order_date ASC（ASC可省略，但显式写出不易错） - 检查
PARTITION BY字段是否真的需要分区——多数场景只需全局累计或按自然周期（如月份）分区 - 用
LAG(cum_sales) OVER (ORDER BY order_date)辅助验证：正常情况下当前累计应 ≥ 前一行累计
真正麻烦的是业务逻辑要求“每月重置累计”——这时不能只靠窗口函数，得结合DATE_TRUNC('month', order_date)（PostgreSQL）或YEAR(order_date)*100 + MONTH(order_date)（MySQL）做分区，否则容易漏掉跨月边界。
