如何实现SQL的分组累加查询：聚合函数与GROUP BY-SQL-PHP中文网

sql中group by无法实现分组内逐行累加，必须用窗口函数sum() over(partition by...order by...)；mysql 5.7等旧版可用变量模拟但不稳定；过滤条件须在窗口外完成，避免逻辑错误。

如何实现sql的分组累加查询：聚合函数与group by

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，结果看起来像断层。