直接用JOIN匹配付款和发票易因多对多关系产生笛卡尔积导致金额重复；窗口函数通过ROW_NUMBER()实现FIFO核销、SUM()OVER()累计核销并验证金额相等，前提是具备明确匹配依据。
为什么直接用 JOIN 匹配付款和发票经常出错
因为一笔付款可能分多次付清多张发票，一张发票也可能被多次付款拆分结清——JOIN 会产生笛卡尔积，金额重复累加，导致汇总失真。窗口函数不是来“替代 JOIN”的，而是帮你按业务逻辑对齐时间线、排序、累计，再做精准匹配。
关键前提是：必须有明确的匹配依据，比如共同的 invoice_id / payment_id，或能通过时间+金额+客户三元组推断关联关系。没有业务规则兜底，再强的窗口函数也救不了数据歧义。
ROW_NUMBER() + 时间排序，解决“最早付款冲最早未结发票”场景
适用于 ERP 中常见的“先进先出（FIFO）”核销逻辑：按付款时间升序，对每笔付款找尚未全额核销的最早发票。
实操建议：
- 先用
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY payment_time)给付款编号 - 对发票用
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY issue_date)编号 - 用编号相等作为临时匹配条件（需配合金额校验），避免跨客户错配
- 注意：若存在同一时间多笔付款/发票，
ORDER BY必须加入唯一字段（如id），否则ROW_NUMBER()结果不稳定
SUM() OVER () 累计核销，识别“哪几笔付款共同结清某张发票”
真正还原业务动作：不是一对一，而是“付款1+付款2=发票A”，这时累计和比单笔更可靠。
常见错误现象：用 SUM(amount) OVER (ORDER BY time) 却没 PARTITION BY invoice_id，导致不同发票的金额混加。
正确做法：
- 把付款表按
invoice_id关联后（哪怕只是左连接试探），再用SUM(payment_amount) OVER (PARTITION BY invoice_id ORDER BY payment_time ROWS UNBOUNDED PRECEDING) - 加上
CASE WHEN cumulative_sum >= invoice_amount THEN 1 ELSE 0 END标记“已结清”点 - 性能注意：大表上
ORDER BY+ROWS UNBOUNDED PRECEDING可能慢，必要时加(invoice_id, payment_time)复合索引
匹配后验证金额是否真正相等，别只信逻辑
窗口函数帮你组织数据，但不保证数学相等。生产中常因四舍五入、预付款抵扣、汇率折算导致差额几分钱。
必须加验证步骤：
- 计算
ABS(SUM(payment_amount) - invoice_amount) （根据币种调整阈值） - 检查匹配结果里是否存在
payment_amount = 0或invoice_amount IS NULL的脏数据 - 用
COUNT(*) OVER (PARTITION BY invoice_id)查出被匹配了 5 次的发票——大概率是关联逻辑漏了过滤条件
真实匹配永远卡在业务规则模糊处：比如部分付款冲账、红字发票冲抵、代付关系。窗口函数只是工具，它不会替你读合同条款。
