SUM()窗口函数适合累计增长因其保留行粒度并按序动态累加，而GROUP BY仅返回分组总量；LAG()配合可算环比，ORDER BY需防重复值导致结果不稳定，且各数据库兼容性差异大。
为什么 SUM() 窗口函数比 GROUP BY 更适合算累计增长
因为累计增长本质是「按时间/顺序逐行叠加」，不是对每个分组整体聚合。用 GROUP BY 只能得到每个分组的最终总量，丢失中间过程；而窗口函数能在保留原始行粒度的同时，动态累加——这才是趋势的骨架。
常见错误现象：SELECT date, SUM(sales) OVER (PARTITION BY region ORDER BY date) FROM t 写成 SELECT region, SUM(sales) FROM t GROUP BY region，结果只有一行/区，根本看不出每天涨了多少。
-
PARTITION BY划定“谁跟谁比”（比如每个region单独算自己的累计） -
ORDER BY决定“怎么累加”（必须明确顺序，否则累计值随机或报错） - 没写
ORDER BY时，SUM() OVER ()默认对整个分区做总和，不是累计
LAG() 和 LEAD() 怎么配合窗口累计算同比/环比增长率
单纯累计和不够，业务常要“比上期涨了多少%”。这时不能只靠 SUM() OVER，得先用 LAG() 拿到上一行的累计值，再手动相减、相除。
使用场景：月度销售报表里“本月累计 vs 上月同期累计”的增长率，或“当日累计 vs 昨日累计”的日环比。
-
LAG(sum_sales, 1) OVER (PARTITION BY region ORDER BY date)拿上一行的累计值，注意第二个参数1表示跨 1 行，别漏写 - 如果首行没有上期数据，
LAG()返回NULL，直接参与除法会得NULL，建议用COALESCE(lag_val, 0)或条件过滤 - 别在
WHERE里过滤掉首行后再算增长率——那样LAG()的偏移逻辑就乱了，应先算完再WHERE
SELECT
date,
region,
SUM(sales) OVER (PARTITION BY region ORDER BY date) AS cum_sales,
(SUM(sales) OVER (PARTITION BY region ORDER BY date) -
LAG(SUM(sales) OVER (PARTITION BY region ORDER BY date), 1)
OVER (PARTITION BY region ORDER BY date))
/ NULLIF(LAG(SUM(sales) OVER (PARTITION BY region ORDER BY date), 1)
OVER (PARTITION BY region ORDER BY date), 0) AS growth_rate
FROM sales_data;ORDER BY 里用多个字段排序时，重复值怎么影响累计结果
当 ORDER BY 字段有重复（比如多笔订单同一天），SQL 标准不保证这些行之间的相对顺序，导致累计值可能每次执行都不一样——这不是 bug，是未定义行为。
性能影响：加唯一排序键（如自增 ID）会让排序更稳定，但也会略微拖慢窗口计算，尤其数据量大时。
- 解决办法是在
ORDER BY末尾补一个能打破平局的字段，比如ORDER BY date, id或ORDER BY date, created_at, order_id - 别用
ORDER BY date, RAND()—— 看似能去重，实则让结果不可复现，查问题时会疯 - 某些数据库（如 MySQL 8.0+）允许用
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW显式声明范围，但前提是ORDER BY已确定
不同数据库对窗口函数累计计算的兼容性差异
核心语法（SUM() OVER）基本通用，但细节上坑不少：PostgreSQL 最宽松，MySQL 8.0+ 才支持，SQL Server 要注意 ROWS 子句默认行为，而旧版 Hive 或 Spark SQL 可能不支持 NULLS FIRST/LAST。
容易踩的坑：
- MySQL 5.7 及更早版本完全不支持窗口函数，强行写会报错
ERROR 1064，不是语法写错，是版本硬伤 - SQLite 直到 3.25.0 才支持，且不支持
EXCLUDE子句，别想用它跳过当前行再累计 - Oracle 中
SUM() OVER默认就是ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但 PostgreSQL 需显式写才保险
真正麻烦的从来不是“会不会写”，而是“在哪跑得通、哪一行会悄悄变结果”。尤其是跨环境迁移报表 SQL 时，同一个语句在测试库 ok，上线后因数据库小版本差异，累计值突然断层——这种问题很难一眼看出来。
