“余额逐行勾兑”指按业务时间顺序对交易流水逐行计算累计余额，并与下游提供的期望余额比对验证；需用sum() over(order by trans_time, id rows unbounded preceding)确保稳定排序和精确累加，且多账户场景必须加partition by account_id。
什么是“余额逐行勾兑”的真实含义
这不是指银行系统内部的对账逻辑，而是业务上常见的需求：给定一组按时间排序的交易流水（存入/支出），要求每行输出当前累计余额，并验证该余额是否与下游提供的“期望余额”字段一致。窗口函数在这里不是用来替代对账，而是生成可比对的计算值。
关键点在于：ORDER BY 必须严格对应业务时间顺序（如 trans_time），且需处理同一时间点多笔交易的稳定性排序（通常加 id 或 seq_no 作为次序键）。
- 常见错误现象：
Window frame is not specified（PostgreSQL）或结果跳变——本质是未声明ROWS UNBOUNDED PRECEDING - MySQL 8.0+、PostgreSQL、SQL Server 2012+ 支持标准语法；SQLite 3.25+ 可用，但不支持
RANGE帧 - 若原始数据含“期初余额”，需先用
UNION ALL插入首行，再统一开窗，不能靠COALESCE(LAG(...), init_balance)拼凑
用 SUM() OVER() 计算滚动余额的最小可行写法
假设表 account_flow 有字段：id、trans_time、amount（正为存入，负为支出）、expected_balance（下游提供）：
SELECT
id,
trans_time,
amount,
SUM(amount) OVER (
ORDER BY trans_time, id
ROWS UNBOUNDED PRECEDING
) AS calc_balance,
expected_balance,
calc_balance = expected_balance AS is_matched
FROM account_flow;
注意：ROWS UNBOUNDED PRECEDING 是显式声明，不是可选项。省略它在 PostgreSQL 中报错，在 MySQL 中默认行为虽等效，但语义不明确，易被误读为 RANGE（会合并相同时间点的多行，导致金额重复累加）。
-
ORDER BY trans_time, id避免时间相同时的非确定性排序 - 不要用
ORDER BY trans_time DESC再取LAST_VALUE——那是反向累计，不符合“逐行”逻辑 - 如果存在冲正（负向交易抵消前笔），
SUM()自然生效，无需额外判断
如何定位勾兑失败的具体行
单纯加 is_matched 布尔列只能知道哪行错了，但查不出为什么错。真正要调试，得把计算路径拆开：
SELECT
id,
trans_time,
amount,
LAG(calc_balance, 1, 0) OVER (ORDER BY trans_time, id) AS prev_balance,
calc_balance,
expected_balance,
calc_balance - COALESCE(LAG(calc_balance, 1, 0) OVER (ORDER BY trans_time, id), 0) AS delta_check
FROM (
SELECT
id, trans_time, amount,
SUM(amount) OVER (ORDER BY trans_time, id ROWS UNBOUNDED PRECEDING) AS calc_balance
FROM account_flow
) t;
重点看 delta_check 是否恒等于 amount——如果不等，说明上游数据本身有重复插入、漏录或类型转换问题（比如 amount 被当字符串拼接而非数值相加）。
- 常见陷阱：数据库里
amount是DECIMAL(12,2)，但应用层写入时用了浮点数（如32.1→ 实际存成32.099999999999994），导致SUM()累积误差 - 别依赖
ROUND(calc_balance, 2)修复——应从源头保证写入精度 - 勾兑失败时优先查
prev_balance + amount != calc_balance的行，而不是直接对比calc_balance和expected_balance
性能与分区边界要注意什么
单账户流水用 OVER(ORDER BY ...) 没问题，但若表含多账户（account_id），必须加 PARTITION BY account_id，否则跨账户累加毫无意义：
SUM(amount) OVER ( PARTITION BY account_id ORDER BY trans_time, id ROWS UNBOUNDED PRECEDING )
没加 PARTITION BY 却按账户查，结果可能全错，但 SQL 不报错——这是静默逻辑错误，比语法错误更难发现。
- 复合排序字段（
trans_time, id）建议建联合索引：CREATE INDEX idx_acc_time_id ON account_flow(account_id, trans_time, id); - Oracle 中若用
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，时间字段为DATE类型时可能因毫秒截断引发重复计数，坚持用ROWS - 大数据量时，避免在窗口函数中嵌套复杂子查询——先把基础流水过滤好再开窗
真正的难点不在语法，而在于确认 trans_time 是否真的代表业务发生顺序。有些系统用“记账时间”而非“交易时间”，会导致勾兑结果看起来合理，实则掩盖了流程漏洞。
