last_value默认不返回窗口末尾值，因其默认窗口帧为rows between unbounded preceding and current row，仅覆盖当前行及之前行，故结果恒等于当前行值；需显式指定rows between current row and unbounded following（向后看）或rows between unbounded preceding and unbounded following（整分区）才能获取真正末尾值。
LAST_VALUE 为什么默认不返回窗口末尾值
直接写 LAST_VALUE(col) 往往拿不到你预期的“滑动窗口末尾”，因为它的默认窗口帧是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW —— 也就是从第一行到当前行，LAST_VALUE 在这个范围内自然就等于当前行的值。这不是 bug，是设计如此，但和直觉冲突。
要让它真返回窗口末尾（比如最近 3 行里的最后一行），必须显式指定帧范围：
- 用
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING：取当前行及之后所有行的最后一个（适合“向后看”场景） - 更常见的是
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING：整个分区末尾（静态窗口） - 若要“滑动”效果（如每行看前 2 行 + 自己共 3 行的末尾），得写
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW，再配LAST_VALUE
滑动窗口末尾值的正确写法示例
假设按时间排序，想对每条记录取它和前两行共 3 行中 price 的最大值（注意：不是 LAST_VALUE，但常被混淆）——先澄清：LAST_VALUE 返回的是值，不是聚合结果；它只是取窗口内指定位置的原始值。
真正实现“3 行滑动窗口末尾值”的典型写法：
SELECT
ts,
price,
LAST_VALUE(price) OVER (
ORDER BY ts
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
) AS last_in_3rows
FROM trades;
⚠️ 注意：LAST_VALUE 在这个帧里返回的是该 3 行子集的 *最后一行的 price*，也就是 CURRENT ROW 的值 —— 因为帧以 CURRENT ROW 结束。所以这其实等价于直接写 price。要拿到“前一行的 price”，得用 LAG(price, 1)；要拿“3 行窗口里真实末尾”（即第 1 行，如果按升序排），就得反转排序或换帧。
ORDER BY 必须存在，且影响 LAST_VALUE 的行为
没有 ORDER BY，LAST_VALUE 无法确定“末尾”是谁 —— 窗口函数在无排序时行为未定义，多数数据库（如 PostgreSQL、SQL Server）会报错，MySQL 8.0+ 也要求显式 ORDER BY。
一款AI工具，主要用于自动分析崩溃并修复错误。监控 Cloudflare D1 崩溃报告，进行去重和 Codex 5.3 High 分析，生成修复并创建...，适合需要提升相关任务效率的用户。
排序方向很关键：
-
ORDER BY ts ASC：窗口末尾 = 时间最晚的那行 -
ORDER BY ts DESC：窗口末尾 = 时间最早的那行（可能反直觉） - 若想让
LAST_VALUE返回物理上“最后进入窗口的那条记录”，确保ORDER BY和业务时间逻辑一致
替代方案：LAG 比 LAST_VALUE 更适合“取前 N 行末尾”
如果你实际想表达的是“取当前行往前第 N 行的值”，比如“前一个价格”“前第二个价格”，别硬套 LAST_VALUE —— 它不是为这种偏移设计的。
直接用 LAG 更清晰、高效、不易出错：
SELECT ts, price, LAG(price, 1) OVER (ORDER BY ts) AS prev_price, LAG(price, 2) OVER (ORDER BY ts) AS prev2_price FROM trades;
LAST_VALUE 真正适用的场景是：你需要在动态窗口中（比如按类别分组、按时间滚动）稳定提取该窗口逻辑上的“终点值”，且这个终点由排序和帧共同定义。一旦窗口帧和排序没对齐，结果就会和预期差一截。
最容易被忽略的一点：不同数据库对 LAST_VALUE 的默认帧处理略有差异（如 Oracle 默认是 RANGE 帧），跨平台迁移时务必验证帧语义是否一致。
