FIRST_VALUE默认窗口帧为UNBOUNDED PRECEDING TO CURRENT ROW，无法稳定取期初余额；必须显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，并确保ORDER BY字段唯一、非空，且分区逻辑与业务口径严格对齐。
为什么直接用 FIRST_VALUE 算期初余额常出错
因为 FIRST_VALUE 默认窗口帧是 UNBOUNDED PRECEDING TO CURRENT ROW，不是整个分区起点。如果你没显式指定 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，它可能只看到当前行及之前的数据，导致首行值拿不准——尤其当排序字段有重复、或存在多条相同时间的记录时，数据库可能任意选一个作为“first”，结果不稳定。
实际场景中，期初余额应取该账户/科目在统计周期内**第一条有效记账记录**的余额（或期初初始化值），而非按默认帧范围“碰巧”拿到的值。
- 必须显式写全窗口定义：
FIRST_VALUE(balance) OVER (PARTITION BY account_id ORDER BY trans_date ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) - 若期初值不来自明细表（比如单独存于期初表），别硬套
FIRST_VALUE，先LEFT JOIN期初快照更可靠 - 注意
ORDER BY字段不能为NULL，否则FIRST_VALUE可能跳过或行为不一致；建议补COALESCE(trans_date, '1970-01-01')或过滤掉空日期
期末余额不能只靠 FIRST_VALUE 倒排
有人试 FIRST_VALUE(balance) OVER (PARTITION BY account_id ORDER BY trans_date DESC ...) 想取最后一条，但风险很大：如果最后几笔是同一天的多条冲正/调整，倒序后 FIRST_VALUE 仍可能随机取其中一条，无法保证是业务上真正的“期末快照”。
真正稳妥的做法是：先用 MAX(trans_date) 找出每个账户的最晚记账日，再关联取当天最后一笔（按序号或主键）的余额；或者改用 LAST_VALUE + 正确帧定义。
- 推荐组合：
LAST_VALUE(balance) OVER (PARTITION BY account_id ORDER BY trans_date, id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)—— 关键是把唯一排序字段（如自增id）加进ORDER BY，避免并列 -
LAST_VALUE默认帧和FIRST_VALUE一样，也必须写全ROWS子句，否则无效 - 若只需期末数值（不要整行），用子查询聚合比窗口函数更直观：
(SELECT balance FROM ledger l2 WHERE l2.account_id = l1.account_id ORDER BY trans_date DESC, id DESC LIMIT 1)
期初/期末要对齐同一维度，否则数字会“漂移”
常见错误：期初用 PARTITION BY account_id，期末却按 PARTITION BY account_id, currency 计算，导致同一账户不同币种混算，或某币种无交易时期末为空而期初有值。
窗口函数的分区逻辑必须严格一致，且与业务口径对齐——比如按“账户+币种+会计期间”三维分组，那所有 PARTITION BY 都得写全这三个字段。
- 检查
PARTITION BY列是否都参与了GROUP BY（如果外层有聚合）或WHERE过滤条件，避免隐式裁剪分区 - 若需跨期间计算（如月报中每个账户的当月期初=上月期末），
FIRST_VALUE就不再适用，得用LAG或自连接查上期结果 - 测试时用
SELECT account_id, trans_date, balance, FIRST_VALUE(balance) ..., LAST_VALUE(balance) ...把中间结果打出来，肉眼核对前/后三行是否符合预期
性能隐患：窗口函数在大数据量下容易拖慢查询
FIRST_VALUE 和 LAST_VALUE 在 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 下，数据库需缓存整个分区的所有行，内存开销大；若分区数据超百万行，可能触发磁盘临时表甚至 OOM。
尤其当分区键基数低（比如全表就 3 个账户）、但总行数极大时，问题最明显。
- 优先考虑用索引优化：确保
(account_id, trans_date, id)有联合索引，让排序和定位更快 - 如果只关心每个账户的首尾两条，用
ROW_NUMBER()分别标出首尾再过滤，通常比全量窗口快：ROW_NUMBER() OVER (PARTITION BY account_id ORDER BY trans_date, id) = 1 - 生产环境务必加
EXPLAIN ANALYZE看实际执行计划，关注WindowAgg节点的Buffers和Actual Total Time
真正难的不是写出 FIRST_VALUE 语法，而是确认它取到的那条记录，在业务逻辑里是否就是你要的“期初”——这取决于你怎么定义“第一笔”，以及数据里有没有隐藏的并发写入、时钟误差、补录单据。别信默认行为，每个 ORDER BY 和每条 ROWS 都得亲手验过。
