借贷轧差是同一账户按时间顺序累计净余额的动态计算过程，不能直接用group by，因其仅能返回分组总和而丢失逐笔余额变化；必须用sum() over(partition by account_id order by transaction_time)窗口函数实现。
什么是借贷轧差，为什么不能直接用 GROUP BY？
借贷轧差本质是同一账户在不同时间点的累计净余额计算，不是简单求和。如果用 GROUP BY account_id 加 SUM(amount)，只能得到期末总余额，丢失每笔交易后的动态余额变化——而财务对账、流水核验恰恰依赖这个过程。
窗口函数的核心价值就在这里：它能在保留原始行粒度的前提下，按业务逻辑（如按时间排序）累积计算。关键不是“能不能算”，而是“在哪一维度上累积”。
- 必须按
account_id分区，否则跨账户累加毫无意义 - 必须按
transaction_time排序，时间错乱会导致轧差结果完全失真 - 金额字段需明确区分借方/贷方：常见做法是借方为正、贷方为负，或统一用
amount字段带符号
ROLLUP 还是 SUM() OVER？选错就全错
ROLLUP 是分组聚合的扩展语法，生成的是多级汇总行（如小计、总计），不保留明细行，也不支持按序累积——它根本不是窗口函数，和轧差无关。真正要用的是 SUM() OVER()。
典型错误写法：SELECT ..., SUM(amount) FROM t GROUP BY account_id, ROLLUP(transaction_time) —— 这会产生大量冗余分组，且无法表达“第3笔交易后余额=前3笔之和”这种逻辑。
- 正确结构：
SUM(amount) OVER (PARTITION BY account_id ORDER BY transaction_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) -
ROWS BETWEEN ...必须显式指定，否则某些数据库（如 PostgreSQL）默认行为可能不符预期 - MySQL 8.0+ 和 SQL Server 2012+ 支持标准语法；旧版 MySQL 需用变量模拟，但易出错且不可并发
如何处理冲正、红字凭证这类特殊交易？
财务系统中，“红字冲销”或“反向凭证”会表现为负向正向金额并存，比如一笔 +100 的收入，后续一笔 -100 的冲正。窗口函数本身不识别业务语义，只认数值，所以必须在数据清洗阶段就完成标准化。
- 确保所有
amount已按借贷方向统一符号：例如借方记为正，贷方记为负；或统一用debit/credit两列，再用COALESCE(debit, 0) - COALESCE(credit, 0)计算净额 - 避免在窗口函数里嵌套条件判断，如
SUM(CASE WHEN type='CREDIT' THEN -amount ELSE amount END) OVER(...)—— 可读性差，且容易漏掉新类型 - 时间戳必须精确到毫秒级（或至少秒级），否则同秒内多笔交易排序不稳定，导致轧差结果非确定性
性能陷阱：ORDER BY 走不走索引？
窗口函数的 ORDER BY 子句若无法命中索引，大数据量下会触发全局排序，I/O 和内存开销陡增。这不是语法问题，是执行计划问题。
- 必须在
(account_id, transaction_time)上建联合索引，顺序不能颠倒 - 避免在
ORDER BY中使用函数，如ORDER BY DATE(transaction_time)—— 索引失效 - PostgreSQL 中可加
NULLS LAST显式控制空值位置，防止因空时间戳导致排序异常 - 测试时用
EXPLAIN ANALYZE看是否出现WindowAgg节点配合Sort，若有且数据量 >10 万行，就要查索引
轧差计算看着只是加加减减，但一旦涉及千万级流水、多币种、跨机构对账，窗口函数的分区键选择、排序稳定性、索引覆盖缺一不可。最容易被忽略的不是语法，而是时间戳精度和冲正数据的前置标准化——这两点出问题，结果看起来“算得出来”，实则全是错的。
