SQL 累计求和必须用 SUM() OVER(ORDER BY …)，窗口函数是唯一稳定高效方式；漏写 ORDER BY 会导致结果随机，多字段排序需显式处理 NULL 和重复值。
SQL 累计求和必须用 SUM() OVER()，没有替代捷径
窗口函数是唯一能稳定、高效、语义清晰地实现逐行累计求和的方式。老式自连接或子查询虽然理论上可行，但数据量一过万行就明显变慢，且容易因排序不明确导致结果错乱。
关键在于：SUM() 本身不能累计，必须配合 OVER() 子句定义“从哪累到哪”。漏写 ORDER BY 是最常见错误——它会导致累计逻辑失效，结果看似有数，实则随机。
-
OVER(ORDER BY date)：按日期顺序累加，适合时间序列报表 -
OVER(PARTITION BY category ORDER BY date)：先分组再各自累计，比如每个产品线独立算销量累计 - 如果只写
OVER()不带任何参数，相当于对整张表求总和，每行都显示同一个总数，不是累计
ORDER BY 在 OVER() 里不是可选的，而是强制依赖
累计求和本质是“有序叠加”，数据库必须知道行与行之间的先后关系。不指定 ORDER BY，SQL 标准允许引擎按任意物理顺序处理，结果不可重现。
常见翻车现场：SUM(sales) OVER(PARTITION BY region) 看似合理，但没 ORDER BY 就等于让数据库自己猜顺序。同一语句执行两次，可能得到两套不同累计值。
- 业务上要求“按下单时间累计”，就必须用真实时间字段，别用自增 ID 替代（ID 不一定等于业务时序）
- 多个字段排序时，务必补全
NULLS LAST或NULLS FIRST，避免 NULL 值挤在开头 / 结尾打乱逻辑 - PostgreSQL 和 Oracle 默认
NULLS LAST，MySQL 8.0+ 和 SQL Server 则默认NULLS FIRST，跨库迁移时要显式声明
累计求和遇上重复时间戳，ROW_NUMBER() 可能比 RANK() 更稳
当多条记录共享同一个 ORDER BY 字段值（比如同秒下单、同日入库），仅靠 ORDER BY timestamp 无法确定它们内部顺序，窗口函数会把这批“并列行”当成一个整体来累加——前一行的累计值直接跳到这批行末尾，中间断层。
解决思路是引入确定性次序。比起依赖业务字段，更可靠的是用 ROW_NUMBER() OVER(……) 构造唯一排序键。
- 错误示范：
SUM(val) OVER(ORDER BY event_time)→ 并列时间下，累计值“跳变” - 稳妥做法：
SUM(val) OVER(ORDER BY event_time, id)或SUM(val) OVER(ORDER BY event_time, ROW_NUMBER() OVER(ORDER BY id)) - 注意：
RANK()和DENSE_RANK()仍会产生并列序号，不能解决排序歧义，只适合排名场景
MySQL 8.0+ 和旧版兼容方案差异大，别硬套语法
MySQL 在 8.0 才正式支持窗口函数，5.7 及更早版本不识别 OVER()，报错是 ERROR 1064 (42000)。强行改写成变量方案（@sum := @sum + val）看似能跑，但有严重隐患：
- 变量赋值顺序受执行计划影响，
ORDER BY和变量更新可能不同步，结果不可靠 - 在子查询、JOIN 或视图中极易失效，MySQL 官方文档明确标注变量用法“不保证行为一致”
- 如果必须兼容老版本，优先考虑应用层累计，或升级 MySQL
真正需要警惕的，是那些看起来跑通了、数值也“差不多”的变量写法——它掩盖了非确定性，上线后某天数据量变大或优化器换策略，累计值就悄悄错位了。
