窗口函数实现财务核对自动化关键在于将核对逻辑内嵌查询：lag()/lead()用于前后行验证，sum() over支持累计求和，count() over可定位重复/断号凭证，但需精准设置partition by和order by以确保账套隔离与顺序正确。
窗口函数本身不自动核对，但能帮你把核对逻辑一次性写进查询里，避免反复导出、Excel比对、人工翻查——这才是财务核对自动化的关键落点。
为什么 LAG() 和 LEAD() 是最常用的核对起点
财务流水常需前后行比对：比如“本期余额 = 上期余额 + 本期发生额”，一旦某行计算结果与实际余额不符，就暴露差异。用 LAG() 拿上一行的余额，LEAD() 拿下一行的发生额，就能在单次查询中完成逐行验证。
- 必须按业务时间（如
trans_date）和账套维度（如account_id）排序并分区，否则LAG()拿到的不是逻辑上的“上期” - MySQL 8.0+、PostgreSQL、SQL Server 2012+ 支持；旧版 MySQL 或 SQL Server 2008 需改用自连接，性能差且易出错
- 空值处理要显式：比如
LAG(balance, 1, 0) OVER (...)中第三个参数设默认值，避免整列因一处 null 失效
SUM() OVER (ORDER BY ... ROWS BETWEEN ...) 怎么替代累计求和脚本
财务底表常缺“累计发生额”字段，但核对收入/支出趋势时又必须依赖它。用带范围的窗口 SUM，比在应用层循环累加或写存储过程更稳、更可审计。
-
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW是标准累计写法；若只算近3期，写成ROWS BETWEEN 2 PRECEDING AND CURRENT ROW - Oracle 中
RANGE默认行为可能因时间精度（秒/毫秒）导致重复值被合并，务必改用ROWS - 大数据量时，
ORDER BY字段必须有索引，否则窗口函数会触发全局排序，查询从秒级变分钟级
用 COUNT() OVER (PARTITION BY ...) 快速定位重复凭证或断号
凭证号重复、流水号跳号是财务系统高频问题。传统做法是 GROUP BY voucher_no HAVING COUNT(*) > 1，但只能返回异常凭证号，无法看到上下文。窗口函数能保留原始行并打标。
- 写成
COUNT(*) OVER (PARTITION BY voucher_no)，再在外层WHERE cnt > 1，就能查出所有重复凭证的完整记录（含时间、金额、操作人） - 查断号：先用
ROW_NUMBER() OVER (ORDER BY voucher_no)生成连续序号，再对比voucher_no - ROW_NUMBER()是否恒定；突变处就是断点 - 注意
PARTITION BY要覆盖多账套场景，比如加上company_code，否则跨公司凭证号冲突会被误判
真正难的不是写出窗口函数，而是把财务规则准确翻译成 OVER 子句里的 PARTITION BY 和 ORDER BY——少一个维度，核对结果就可能跨账套污染；顺序错一位，累计值就全偏移。上线前务必用已知异常数据反向验证输出。
