SQL中GROUP BY无法实现分组内逐行累加，必须用窗口函数SUM() OVER(PARTITION BY...ORDER BY...)；MySQL 5.7等旧版可用变量模拟但不稳定；过滤条件须在窗口外完成，避免逻辑错误。
GROUP BY 后不能直接用 SUM() 累加“到当前行为止”
SQL 标准的 GROUP BY + SUM() 只能算每组的总和，不是“分组内逐行累加”。想实现“每个分组里，按时间/序号累加”，得靠窗口函数——不是聚合函数配 GROUP BY 能搞定的。
常见错误现象：SELECT user_id, order_time, SUM(amount) OVER (PARTITION BY user_id ORDER BY order_time) AS cumsum FROM orders; 这句没错，但如果你写成 SELECT user_id, SUM(amount) OVER (ORDER BY order_time) ... GROUP BY user_id，会报错或结果错乱——GROUP BY 和窗口函数混用时，GROUP BY 会先压缩行，窗口函数再跑就失去原始粒度了。
- 必须确保原始数据有明确排序依据（比如
order_time或自增id），否则ORDER BY在窗口里无意义 -
PARTITION BY定义分组边界，ORDER BY定义组内累加顺序，缺一不可 - MySQL 8.0+、PostgreSQL、SQL Server 2012+、Oracle 支持；SQLite 3.25+ 也支持，但旧版不认
SUM() OVER
MySQL 5.7 或更老版本怎么绕过窗口函数限制
没 OVER 就没法写标准累加，但可以用变量模拟。注意：这是兼容方案，不是推荐写法，稳定性差、并发下易出错、不可预测。
典型错误现象：变量初始化位置不对，导致第一次查询结果正常，第二次就归零或跳变；或者在子查询里没强制排序，@sum := @sum + amount 执行顺序混乱。
- 必须用
(SELECT @sum := 0) AS _init在FROM子句里显式初始化变量 - 主表必须套一层
ORDER BY子查询，确保变量按序执行：SELECT user_id, amount, @sum := @sum + amount AS cumsum FROM (SELECT * FROM orders ORDER BY user_id, order_time) t, (SELECT @sum := 0) r; - 不能在视图或存储过程中依赖该写法——MySQL 8.0 后官方已标记用户变量为“不建议用于计算”，后续版本可能移除语义保证
分组累加结果要带“组内最大值”或“最新时间”，别漏掉 LAST_VALUE()
光有累加还不够，业务常要“截至当前，这组最高金额是多少”或“最后一次下单时间”。这时候别手写子查询关联，用窗口函数一步到位。
容易踩的坑：MAX(amount) OVER (PARTITION BY user_id ORDER BY order_time) 算的是“从头到当前”的最大值，但如果你想要“整组最大值”，就得去掉 ORDER BY，只留 PARTITION BY；而 LAST_VALUE(order_time) 默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，不加 ROWS BETWEEN 会返回 NULL——因为默认框架不含当前行之后的行，而 LAST_VALUE 想取“组内最后”，得显式写 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING。
- 取组内全局最大值：
MAX(amount) OVER (PARTITION BY user_id) - 取组内按序到最后一个值：
LAST_VALUE(order_time) OVER (PARTITION BY user_id ORDER BY order_time ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) - 性能影响：多加一个窗口函数，基本不额外开销，执行计划仍是一次扫描；但别堆十几个不同
OVER，尤其跨不同PARTITION BY，可能触发多次重排
WHERE 条件写在窗口函数外面，不然逻辑全错
很多人想“只对近30天订单做分组累加”，于是把 WHERE order_time >= '2024-01-01' 塞进子查询里——这没问题；但如果误写成 SUM(amount) OVER (PARTITION BY user_id ORDER BY order_time) WHERE order_time >= ...，语法直接报错。更隐蔽的错法：在窗口函数里用 CASE WHEN 过滤，比如 SUM(CASE WHEN order_time >= '2024-01-01' THEN amount ELSE 0 END) OVER ...，这看似可行，但会导致“累加基线被污染”——早于30天的记录仍占位置，只是加 0，结果看起来像断层。
- 过滤必须在最外层或子查询中完成，确保输入窗口函数的数据集已干净
- 如果真要动态控制“从哪一行开始累加”，用
ROWS BETWEEN N PRECEDING AND CURRENT ROW，而不是靠CASE填 0 - PostgreSQL 中
FILTER (WHERE ...)可以安全过滤聚合，但不适用于窗口函数中的累加逻辑
窗口函数的 PARTITION BY 和 ORDER BY 是绑定的，改一个就得同步看另一个；变量方案看着短，但上线前务必压测并发场景——那点“省事”可能换来半夜告警。
