用sum(column) over (order by key_column)可实现逐行累计求和，必须指定order by，否则默认全表求和而非累计；默认窗口为rows between unbounded preceding and current row，排序字段需有明确顺序且避免重复，必要时加唯一字段辅助排序。
SQL里怎么用SUM() OVER()做累计求和
直接说结论：用SUM(column) OVER (ORDER BY key_column)就能实现类似Excel里“从上到下累加”的效果，但必须注意ORDER BY子句不可省略——不写就默认按未定义顺序计算，结果不可控，不是真累计。
常见错误是只写SUM(x) OVER()，看起来语法对，实则等价于全表求和（即每个行都显示同一总值），根本不是累计。真正累计依赖窗口的“帧”（frame）默认行为：ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，它隐含在ORDER BY存在时，但不会自动启用。
-
ORDER BY字段必须有明确语义顺序，比如时间戳order_date、序号id，不能是重复率高且无序的字段（如status） - 如果排序字段有重复值，累计值会在这些行“堆叠”——即同序号的多行共享同一个累计结果（因
CURRENT ROW包含所有并列行） - 想打破并列、强制逐行累计？加一个唯一字段进
ORDER BY，例如ORDER BY order_date, id
累计折线图需要的数据结构长什么样
画折线图（比如用Python的matplotlib或BI工具）要求数据是“时间点→累计值”的二维序列，SQL输出必须是两列：横坐标（如日期）、纵坐标（累计和）。不能有多余分组干扰顺序。
典型陷阱是误加GROUP BY：一旦用了GROUP BY，OVER()作用域就变成每组内独立累计，而非全表连续累计。如果你本意是“每天新增数→每日累计总数”，得先聚合出每日新增，再对聚合结果套SUM() OVER()。
- 正确链路：
SELECT day, SUM(cnt) AS daily_new FROM t GROUP BY day→ 外层再套SUM(daily_new) OVER (ORDER BY day) - 错误写法：
SELECT day, SUM(cnt) OVER (ORDER BY day) FROM t GROUP BY day—— 这里OVER()在GROUP BY后执行，但语法上会报错（除非cnt也在GROUP BY里，那就失去聚合意义） - 别忘了
ORDER BY要跟外层查询一致，否则图表X轴会乱序
不同数据库对SUM OVER的兼容性差异
主流数据库都支持标准窗口函数，但细节有坑。PostgreSQL和SQL Server最规范；MySQL 8.0+才支持，5.7及以前完全不可用；SQLite直到3.25+才引入，且不支持ROWS帧语法（但默认累计逻辑仍可用）。
Oracle有个老习惯：用ORDER BY时若没显式指定ROWS范围，可能触发RANGE语义（按值范围而非行位置），导致重复值被合并累计——这在时间字段上尤其危险（比如同一天多条记录只算一次）。稳妥做法是显式写死：
SUM(sales) OVER (ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
- BigQuery和Snowflake默认
ROWS语义，不用额外声明 - 如果遇到“窗口函数不支持ORDER BY”的报错，先查版本，再确认是否漏了
OVER括号或拼写（如写成OVER ORDER BY少括号） - 性能上，
ORDER BY字段最好有索引，否则大表排序开销明显
为什么累计值和Excel拖拽结果对不上
最常忽略的一点：Excel的“累计求和”默认按**当前区域可见行顺序**计算，而SQL的ORDER BY按字段值排序——如果原始数据本身是乱序的，又没指定排序依据，结果必然不一致。
另一个隐蔽差异是NULL处理：SUM()跳过NULL，但Excel中空单元格有时被当0参与累加。检查你的源数据是否有NULL，必要时用COALESCE(amount, 0)兜底。
- 导出到Excel前，用
SELECT * FROM (...) ORDER BY x确保最终顺序可预期 - BI工具里若累计线断续，大概率是SQL返回的横坐标有跳跃（比如缺某天数据），得补全日期维度，用
LEFT JOIN或GENERATE_DATE_ARRAY（BigQuery）对齐 - 别依赖客户端排序——SQL层必须把顺序和值都算准，下游只负责渲染
