新加坡 11-08 01:20 · 吉隆坡 01:20 · 雅加达 00:20 · 曼谷 00:20 · 马尼拉 01:20 · 胡志明 00:20 · 北京 01:20 · 东京 02:20 · 伦敦 17:20 · 纽约 12:20
Amy 原创整理｜资料核验：2026-11-07
PostgreSQL 的 last_value 取的是当前窗口框架最后一行，而不一定是整个分组的最后一行。使用 ORDER BY 又没有明确写出框架时，默认框架通常只到当前行的同序值末尾。
教学示例：同组的三条记录依次为 10、20、30，排序键各不相同，默认写法在首行看到的末值可能就是 10。若业务需要三行都带上组内最终值，可在 OVER 中明确写 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，并用能确定先后次序的键排序。
官方来源：
https://www.postgresql.org/docs/current/functions-window.html
补一个容易踩的坑：排序键有并列值时，默认框架是 RANGE 语义，会延伸到「同序值」的最后一行，所以 tie 多的表上 last_value 会停在并列段末尾，前后行看到的值还会跳；要按物理行算就写 ROWS 而不是 RANGE。另外很多人的测试 SQL 没写 ORDER BY，这时默认框架覆盖整个分区，last_value 恰好返回组末值，看起来「正常」，一加 ORDER BY 就变脸——这才是它显得诡异的根源。ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 加确定唯一先后的排序键是稳的写法；只要组末值也可以考虑 window 里 first_value 倒序取或干脆用聚合 max/窗口聚合一次算好。