用 SUM() 窗口函数实现 GROUP BY 后的累计和，需同时指定 PARTITION BY 分组和 ORDER BY 排序，二者缺一不可；MySQL 与 PostgreSQL 语法相似但 NULL 处理不同，须显式控制；累计增长量需先算累计再用 LAG() 求差。
GROUP BY 后怎么加累计和？用 SUM() 窗口函数最直接
窗口函数是唯一能不破坏分组结构、又算出组内累计值的方法。用 GROUP BY 配合普通 SUM() 只能得到每组总和，没法保留原始行；想在每行显示“从第一行加到当前行”的值，必须上 SUM() OVER ()。
常见错误现象：SELECT a, b, SUM(b) FROM t GROUP BY a 报错或结果不对；或者写成 SUM(b) OVER (PARTITION BY a) 却没加 ORDER BY，导致累计顺序混乱（默认无序，结果不可预测）。
- 必须显式写
ORDER BY在OVER里，比如SUM(b) OVER (PARTITION BY a ORDER BY id) -
PARTITION BY定义分组边界，ORDER BY定义组内累计顺序，二者缺一不可 - 如果原始数据没天然排序字段，得先用
ROW_NUMBER()或时间戳补一个，否则累计逻辑可能漂移
MySQL 8.0+ 和 PostgreSQL 的 SUM() OVER 写法一致吗？
语法层面几乎一样，但 MySQL 对空值和严格模式更敏感。PostgreSQL 默认允许 ORDER BY 字段为 NULL，MySQL 会把它排在最前，可能影响累计起点。
使用场景：迁移旧 SQL 到新版本时，发现累计值突然偏移，大概率是 NULL 排序行为差异导致的。
- 统一做法：在
ORDER BY中显式处理空值，例如ORDER BY created_at ASC NULLS LAST（PostgreSQL 支持），MySQL 改用ORDER BY IFNULL(created_at, '1970-01-01') - MySQL 5.7 不支持窗口函数，强行运行会报错
ERROR 1064: You have an error in your SQL syntax，得先确认版本 - 性能上，只要
ORDER BY字段有索引，累计计算基本是线性扫描，不触发临时表
累计增长要“比上期增多少”？别硬套 LAG() 再减
直接用 SUM() 窗口函数只能得到累计值，要算“当期相比上期的增长量”，本质是行间差值，不是累计逻辑。这时候 LAG() 是正确工具，但容易误用。
常见错误现象：写成 SUM(b) - LAG(SUM(b)) OVER (……)，结果报错或全为 NULL——因为聚合和窗口不能混在同一层表达式里。
- 正确路径：先用窗口函数算出累计值（如
cum_sum），再用LAG(cum_sum)做差，两步分离 - 示例：
SELECT x, cum_sum, cum_sum - LAG(cum_sum, 1, 0) OVER (PARTITION BY a ORDER BY t) AS delta -
LAG(……, 1, 0)第三个参数设默认值，避免首行返回NULL，不然delta第一行就是空
累计值不准？检查这三件事：排序字段重复、NULL、没分区
窗口函数的累计结果看起来“跳变”或“平直”，通常不是函数写错了，而是数据特征没对齐预期。
使用场景：报表中某类用户分组的累计充值金额突然断层，或一直不变，实际数据明明有波动。
- 排序字段有重复值（比如多个记录同一天），会导致同序号行累计值相同，且后续行可能跳过——加
ROW_NUMBER()当次序兜底 -
PARTITION BY漏写，整个结果集被当成一组累计，而不是按业务维度（如user_id）分开算 - 排序字段含大量
NULL，MySQL 默认把它们排最前，第一行累计值就包含一堆无效数据
复杂点在于：累计逻辑依赖数据分布本身，不是纯语法问题。调的时候得先 SELECT 出排序字段和原始值，肉眼扫一遍顺序是否符合业务意义。
