SQL LAST_VALUE 为什么取不到最后一条？窗口边界怎么写？

SELECT user_id, event_time, event_id, status,
       LAST_VALUE(status) OVER (
         PARTITION BY user_id
         ORDER BY event_time, event_id
       ) AS frame_last,
       LAST_VALUE(status) OVER (
         PARTITION BY user_id
         ORDER BY event_time, event_id
         ROWS BETWEEN UNBOUNDED PRECEDING
                  AND UNBOUNDED FOLLOWING
       ) AS final_status
FROM order_events;

第一列计算沿默认帧前进，第二列明确看完整个分区。对这组三条且顺序唯一的数据，frame_last 依次是新建、支付、完成，final_status 则三行都是完成。

注意，窗口函数不会自动把三行压成一行。需求如果是“每个用户只保留最后一条事件”，可以按倒序排名再选第一行；那是结果粒度的选择，与给每一行补最终状态不同。

排序不完整，改了窗口也不够

两条事件可能有相同时间。只按 event_time 排序，谁最后并没有被业务规则唯一确定。执行计划变化后，结果可能改变，但这不一定是引擎随机算错。

应补充能表达先后关系的序列、版本或业务事件号。不能随意拿一个字段凑成唯一排序，却没有解释它是否代表真实先后。

事件时间为空也要单独决定处理方式：排除异常、隔离修复，还是明确放在前后。将未知时间默认为最新，可能把一条脏记录推成全组最终状态。

最后一条为空，要不要跳过？

如果末条事件的 status 是 NULL，完整帧的 LAST_VALUE 可以返回 NULL。它不是自动寻找最后一个非空值。

PostgreSQL 17 没有实现这个函数的 IGNORE NULLS 选项；跨引擎复制语法前要先核对能力。业务要取最后非空记录，可以先在独立子查询里筛出有效状态并排名，再关联回原始明细。

但在主查询直接过滤 status IS NOT NULL，会同时改变保留的明细行。对于“明细一行都不能丢”的需求，修复函数时不能顺便改掉结果范围。

一个典型场景：最后状态没有统一

比如验收发现，同一个订单的不同行带着不同“最终状态”，最初以为事件乱序或写入重复。检查后事件顺序完全正常，问题是省略了完整窗口帧。

旧样例每个订单只有一条记录，当前帧末行和全组末行相同，所以错误写法照样通过。新的测试需要覆盖多条变化、相同时间、末行空值，以及两个不同分组。

修复后还应核对输出行数与原明细一致。最终状态统一，不代表允许重复关联或误删行；语义正确和粒度正确要同时成立。

最终值也可能是未来信息

做历史分析时，完整分组里的“完成”可能发生在几天之后。如果为每个历史时点生成特征，把这个最终状态补到过去，就引入了当时尚不可知的信息。

因此要区分“今天回顾完整生命周期”和“还原某时刻已知状态”。前者可以看全组，后者要先限定可用事件范围和时间条件，再决定窗口。

面试里最有价值的不是背出 UNBOUNDED FOLLOWING，而是说清：你想保留多少行、排序代表什么、当前计算允许看多远。

参考资料

• PostgreSQL 17：窗口函数