不加ORDER BY的SUM() OVER()无法得到累计和，因其默认按未定义顺序计算，等价于分组总和而非有序累加；累计和必须显式指定ORDER BY以定义“到当前行为止”的叠加路径。
为什么SUM() OVER()不加ORDER BY得不到累计和
不加 ORDER BY 的窗口 SUM() 默认按“未定义顺序”计算，实际结果等价于全组总和（即每个分组内所有行都显示相同值），根本不是累计。累计和本质是“到当前行为止的有序叠加”，必须显式声明排序依据。
- 错误写法：
SUM(amount) OVER (PARTITION BY category)→ 每行都是该 category 的总金额 - 正确前提：先确定业务上“累计”的自然顺序，比如时间字段
created_at、序号id或状态流转顺序 - 注意：若排序字段存在重复值且无唯一辅助列，可能引发非确定性结果（不同执行返回不同累计值）
如何在分组内做可靠累计（PARTITION BY + ORDER BY）
核心是把 PARTITION BY 和 ORDER BY 同时写进 OVER 子句——前者切分组，后者定义组内累积路径。数据库会为每个分组独立跑一遍有序累加。
- 典型写法：
SUM(amount) OVER (PARTITION BY category ORDER BY created_at, id) - 必须包含唯一性保障：当
created_at可能重复时，追加id等主键字段避免歧义 - 排序方向默认升序（ASC），如需倒序累计（如“剩余未处理量”），用
ORDER BY created_at DESC，但逻辑要自洽 - PostgreSQL/SQL Server/Oracle/MySQL 8.0+ 均支持；SQLite 3.25+ 支持，但旧版不支持窗口函数
累计和结果出现“跳变”或“归零”的常见原因
看似正确的 SQL 却输出不符合预期的累计值，大概率是数据本身或排序逻辑埋了坑。
-
NULL值干扰：amount为NULL时，SUM()会跳过该行，导致累计值“断层”。建议提前用COALESCE(amount, 0) - 分组键不严谨：比如用
PARTITION BY YEAR(created_at)但漏掉月份，把跨年数据混进同一组 - ORDER BY 字段类型不匹配：用字符串格式日期（如
'2023-1-5'）排序，会导致'2023-10-1'排在'2023-2-1'前面 - WHERE 条件位置错误：在窗口函数外过滤（如
WHERE status = 'done'）没问题；但如果在子查询里漏过滤脏数据，累计基数就错了
替代方案：不支持窗口函数的老版本MySQL怎么办
MySQL 5.7 及更早版本不支持 OVER，只能靠变量模拟，但需严格控制执行顺序且不可并行。
- 基础变量法：
SELECT ..., @sum := @sum + COALESCE(amount, 0) AS running_total FROM t, (SELECT @sum := 0) r ORDER BY category, created_at; - 必须带
ORDER BY，否则变量更新顺序不确定 - 分组累计需额外判断：
@prev := category+CASE WHEN @prev = category THEN @sum := @sum + ... ELSE @sum := amount END - 缺点明显：无法在视图或子查询中安全复用；高并发下可能出错；MySQL 8.0+ 已废弃变量赋值语法，仅作兼容过渡
真正需要稳定累计和，升级到 MySQL 8.0+ 并用标准窗口函数是最省心的选择。变量方案只适合临时导出或低频脚本。
