直接用SUM() OVER会算错余额，因它默认从第一行累加到当前行，但账户余额需严格按时间顺序逐笔叠加且必须显式注入期初余额；若数据未排序、存在重复时间戳或缺失起始值，结果必然错乱。
为什么直接用 SUM OVER 会算错余额？
因为 SUM() OVER 默认是“从第一行累加到当前行”，但账户余额必须严格按时间顺序逐笔叠加，且起始余额不能丢。如果原始数据没按时间排序、或存在相同时间戳的多笔交易、或没显式指定起始值，结果必然错乱。
常见错误现象：SUM(amount) OVER (ORDER BY create_time) 算出来的“余额”在某几笔后突然跳变，或首条记录就不是期初余额。
- 必须显式补上期初余额（通常作为第一条虚拟记录或用
UNION ALL拼接） -
ORDER BY子句里必须包含能唯一确定顺序的字段，比如create_time, id，避免同秒多笔导致窗口计算顺序不确定 - 不能依赖表默认顺序——SQL 标准不保证无
ORDER BY的查询顺序
怎么拼出带期初余额的完整流水？
最稳妥的做法是把期初余额当作一笔“0号交易”插进去，再统一开窗。假设期初余额为 1000，主表叫 transactions，含字段 id、create_time、amount：
SELECT id, create_time, amount, SUM(amount) OVER (ORDER BY create_time, id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS balance FROM ( SELECT NULL AS id, '2024-01-01 00:00:00'::timestamp AS create_time, 1000 AS amount UNION ALL SELECT id, create_time, amount FROM transactions ) t ORDER BY create_time, id;
注意：ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 是显式写法，虽是默认行为，但写出来更安全——有些旧版 PostgreSQL 或 Oracle 对默认框架有歧义。
遇到负数、NULL 或并发更新怎么办？
amount 字段为 NULL 会导致整条窗口计算中断（SUM 遇 NULL 返回 NULL），而负数本身没问题，但容易掩盖逻辑漏洞。
- 务必用
COALESCE(amount, 0)替换原始amount，防止 NULL 污染整列余额 - 如果业务要求“未确认交易不计入余额”，得先过滤状态，比如加
WHERE status = 'confirmed'，不能靠前端判断 - 并发场景下，仅靠
SUM OVER查不到实时余额——它只是快照计算。真要强一致性，得配合事务 +SELECT ... FOR UPDATE或使用带版本号的余额表
MySQL 8.0 和 SQL Server 的细微差别
MySQL 8.0 支持标准窗口函数，但默认字符集或时区可能导致 create_time 排序异常；SQL Server 则对 ORDER BY 中的 datetime2 和 datetime 类型敏感，精度不同可能让两笔“同一秒”的记录顺序颠倒。
- MySQL：建议显式用
CAST(create_time AS DATETIME(6))统一精度 - SQL Server：优先用
datetime2(3)存储，并在ORDER BY中补上id保序 - 两者都不支持在窗口函数里直接引用别名（比如不能写
SUM(COALESCE(amount,0)) OVER (ORDER BY ts)然后定义ts AS create_time），必须展开写
真正麻烦的不是语法，而是时间字段有没有索引、是否允许空值、以及上游系统写入时有没有做去重和幂等控制——这些不解决，窗口函数再写对也没用。
