SUM OVER不能直接当余额用，因余额需严格按时间逐笔确定性结算；必须用ORDER BY timestamp, id等唯一键+ROWS UNBOUNDED PRECEDING确保稳定性，并统一净变动值、排除NULL、对齐起始余额与时区。
为什么 SUM OVER 不能直接当余额用
因为 SUM() OVER() 默认是累积求和，但账户余额必须严格按时间顺序逐笔结算，且要处理“同一时刻多笔交易”的排序歧义。数据库不保证 ORDER BY 子句中未明确指定唯一排序键时的行序稳定性——比如两笔同秒入账的转账和手续费，没加 id 或 seq_no 二次排序，结果可能每次查询都不一样。
- 必须用
ORDER BY timestamp, id（或带业务唯一性的字段）确保窗口函数逐行确定性累加 - 如果原始表缺少单调递增主键，得先用
ROW_NUMBER() OVER (ORDER BY timestamp, amount)生成临时序号，再套一层窗口 -
SUM(amount) OVER (ORDER BY timestamp, id ROWS UNBOUNDED PRECEDING)才是安全写法；漏掉ROWS UNBOUNDED PRECEDING在部分数据库（如旧版 MySQL）里可能退化为默认范围，行为不可控
如何处理充值、支出、手续费混杂的余额计算
账户流水里 amount 字段正负含义必须统一：建议全部转为“净变动值”，即充值为正、支出与手续费为负。别依赖类型字段（如 type IN ('recharge', 'withdraw', 'fee')）在窗口函数里做条件判断——CASE WHEN 套在 SUM() OVER() 里面虽语法合法，但可读性差、难审计，也容易漏逻辑分支。
- 建视图或 CTE 预处理：把原始流水转成标准净变动列，例如
CASE WHEN type = 'withdraw' THEN -amount ELSE amount END AS net_amount - 对账时只基于
net_amount累加，避免在窗口函数里嵌套多层逻辑 - 特别注意退款场景：一笔“原支出 -100”+“退款 +100”必须保证两条记录都进入计算，不能因
WHERE status = 'success'过滤掉其中一条
对账时发现余额对不上？优先检查这三处
实时余额对账出错，80% 源于数据边界没对齐，而不是窗口函数写错了。
- 起始余额是否显式计入：窗口累加只算变动，初始余额（如开户余额）必须用
COALESCE(first_value(initial_balance) OVER (), 0)或更稳妥地，在外层SELECT中加常量 - 时间过滤是否漏掉“正在处理中”的记录：比如
WHERE status IN ('success', 'pending')，但对账脚本只取status = 'success'，会导致 pending 中的冻结金额未扣除 - 时区陷阱：数据库
timestamp是 UTC，而业务系统日志用本地时区写入，ORDER BY timestamp实际打乱了真实发生顺序
PostgreSQL 和 MySQL 8.0+ 的关键差异点
同样写 SUM(amount) OVER (ORDER BY ts, id)，两个数据库对 NULL 值的处理不同：PostgreSQL 把 NULL 排在最前，MySQL 8.0+ 默认排最后——如果某条流水的 ts 为空（比如补录数据），两边算出来的累计值从第二行开始就全错。
- 强制排除
NULL：WHERE ts IS NOT NULL最干净 - 或统一补默认值：
COALESCE(ts, '1970-01-01'::TIMESTAMP)（PG） /COALESCE(ts, '1970-01-01 00:00:00')（MySQL） - MySQL 8.0.22+ 支持
NULLS FIRST，但 PG 早就有，跨库迁移时这个子句不能直接抄
真正麻烦的是那些没走事务、靠应用层拼 SQL 补单的场景——窗口函数再准，源头数据本身已失序，这时候得回溯到 binlog 或消息队列重放，SUM OVER 只是最后一道验证工具。
