LEAD()是财务对账中识别“下期差异”的直接工具，但需配合OVER子句、PARTITION BY分组、UNION ALL拼接及显式排序才能正确插入差异行并避免跨组取值错误。
LEAD() 是财务对账中识别“下期差异”的最直接工具，但直接 SELECT 中用它只会新增一列，不是新增差异行；真要让“vs 下期”出现在当前行下方，必须配合 UNION ALL 和显式排序序号。
LEAD() 报错 ERROR: window function LEAD requires an OVER clause 怎么办
这是最常见硬性错误：LEAD() 是窗口函数，不能当普通函数用。它绝不能出现在 WHERE、GROUP BY 或 HAVING 中，只能在 SELECT 列表或 ORDER BY 里出现。
-
LEAD(amount)单独写一定报错；必须写成LEAD(amount) OVER (ORDER BY tran_date) -
ORDER BY不可省略——哪怕数据天然有序，缺了它结果就是非确定的（尤其在 Presto/Trino 或分布式引擎上） - 如果要按账期分组对比（比如每个账户各自看下笔交易），必须加
PARTITION BY account_id，否则跨账户取值会串
为什么用 LEAD(amount) 而不是 LAG(amount) 做“下期差异”
语义和位置逻辑决定的。财务对账常需在当前凭证后紧跟着一行“vs 下笔”，比如：
2026-04-01 | 收款 10000 | —<br>2026-04-05 | 付款 8200 | vs 下笔：-1800
这时 LEAD(amount) 取的是下一行的 amount，自然对应“下笔”；而 LAG(amount) 取的是上一笔，算出来是“vs 上笔”，但业务要求的差异行要插在当前行之后，位置就错乱了。
- 用
LAG(amount)写出的差额列，逻辑上属于“上笔 → 当前笔”，但报表要展示的是“当前笔 → 下笔” - 若强行用
LAG()并把结果挪到下一行显示，需额外做行偏移控制，极易出错 -
LEAD(amount, 1, 0)显式指定偏移量和默认值，比隐式调用更可控
如何让差异行真正“插入”在原始数据中间
仅靠 LEAD() 无法新增行，它只扩展列。要实现视觉上的交替排列（原始行 → 差异行 → 原始行 → 差异行…），得用 UNION ALL 拼接两套数据，并用排序字段控制顺序。
- 原始数据子查询中，设
sort_order = 1，SELECT 所有字段 +LEAD(amount) AS next_amount - 差异行子查询中，SELECT 相同字段但用
next_amount填充金额列，其他字段填空或标注“vs 下期”，并设sort_order = 2 - 外层
ORDER BY tran_date, sort_order—— 注意tran_date必须唯一，否则同日多笔时 LEAD() 结果不可控；如有重复，得补上id或seq_no保证稳定排序 - 最后一行的
LEAD()返回 NULL，差异计算要用COALESCE(next_amount - amount, 0)，避免整行变 NULL
分组对账时 PARTITION BY 忘加或加错的后果
财务数据常按科目、账户、币种分组独立对账。漏掉 PARTITION BY 会让 LEAD() 在全量数据中找“下一行”，导致跨科目取值——比如银行存款的下一笔可能是应收账款，差额完全失真。
- 正确写法：
LEAD(amount) OVER (PARTITION BY account_code ORDER BY tran_date, id) - 错误写法：
LEAD(amount) OVER (ORDER BY tran_date)—— 全局排序，组间污染 - 如果分组字段本身有 NULL（如未分配科目的凭证），
PARTITION BY account_code会把所有 NULL 归为一组，需提前WHERE account_code IS NOT NULL过滤 - 排序字段没索引时，
OVER (PARTITION BY ... ORDER BY ...)可能拖慢数倍，尤其千万级流水表
真正难的不是写出 LEAD()，而是确保 ORDER BY 在每组内绝对稳定、PARTITION BY 边界不越界、以及用 UNION ALL 拼接时两套数据的字段类型和 NULL 处理完全一致——这三个地方出错，对账结果可能无声无息地错掉几百万。
