LAST_VALUE() 默认返回当前行值，因窗口帧为ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW；需显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING或改用ROW_NUMBER()获取整行最新记录。

LAST_VALUE() 本身不会自动“定位最后一条记录”，它只在指定窗口内返回该窗口最后一行的值；想动态锚定物理末尾，必须配合 ORDER BY 和 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING 或显式定义窗口边界。

为什么直接用 LAST_VALUE() 常常返回当前行的值？

默认窗口帧是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，这意味着 LAST_VALUE() 只看从开头到当前行为止的数据段——所以它几乎总等于当前行的值（除非有重复排序键）。这不是 bug，是设计如此。

• 错误写法：LAST_VALUE(col) OVER (ORDER BY ts) → 实际等价于 LAST_VALUE(col) OVER (ORDER BY ts ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
• 正确思路：要拿到“从当前行开始直到整个分区结尾”的最后一个值，得把窗口下界设为 CURRENT ROW，上界设为 UNBOUNDED FOLLOWING
• 注意：某些数据库（如 PostgreSQL）不支持 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING，此时需改用 ROWS BETWEEN CURRENT ROW AND (SELECT COUNT(*) FROM t) - ROW_NUMBER() OVER (ORDER BY ts) ROWS 这类迂回方案（不推荐，性能差）

如何用 LAST_VALUE() 获取每个分组中按时间排序的最后一条完整记录？

LAST_VALUE() 只能取单个字段值，不能直接“取出整行”。若需整行数据（比如最新订单的 id、amount、status），应避免硬套 LAST_VALUE()，改用带 ROW_NUMBER() 的子查询或 FIRST_VALUE() 配合逆序排序。

• 安全做法：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) = 1 过滤出每组最新行
• 强行用 LAST_VALUE() 的代价：需对每个字段单独调用，例如：LAST_VALUE(id) OVER (PARTITION BY user_id ORDER BY created_at ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)，但结果会广播到所有行，且无法保证各字段来自同一原始记录（排序键相同时可能错配）
• MySQL 8.0+、PostgreSQL 13+、SQL Server 2012+ 支持 QUALIFY（BigQuery / Snowflake）或 LATERAL JOIN，比拼凑 LAST_VALUE() 更可靠

LAST_VALUE() 在实时滚动窗口（如最近 7 天）中怎么保持动态更新？

LAST_VALUE() 是静态窗口函数，不感知“当前系统时间”或“滑动范围”。所谓“最近 7 天”，必须由 WHERE 或 CTE 显式过滤数据，再在其结果集上开窗。

• 正确结构：

  SELECT *,
    LAST_VALUE(price) OVER (
      ORDER BY event_time 
      ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
    ) AS last_price_in_tail
  FROM events 
  WHERE event_time >= CURRENT_DATE - INTERVAL '7 days'

• 错误假设：认为 LAST_VALUE() OVER (ORDER BY t ROWS BETWEEN ...) 能自动随新数据流入刷新“最后”——它只作用于当前查询快照，不维护状态
• 如果底层表持续追加，每次查询都要重跑全量 WHERE + 窗口，无法增量计算；高频场景建议用物化视图或应用层缓存 last_value

真正难的不是语法，而是想清楚“最后”到底相对于什么：是整个表、某个 GROUP、还是某段连续时间？一旦窗口定义和业务语义对不上，LAST_VALUE() 返回的就只是巧合正确的数字。