LAST_VALUE不能直接获取分组内最后一次变动的完整记录，因其默认窗口框架仅限当前行及之前，须显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING并配合确定性排序；真正可靠的方式是用ROW_NUMBER()按变动时间倒序编号后筛选rn=1的行。
LAST_VALUE 真的不能直接拿“分组内最后一次变动记录”
LAST_VALUE 是窗口函数，但它默认的 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 框架决定了：它返回的是「当前行及之前所有行中的最后一个值」，不是整个分组的最后一条。想靠它直接取每组最新记录，结果往往错位——特别是当排序字段有重复、或你没显式指定 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 时，LAST_VALUE 会返回当前行位置上的“局部末尾”，不是真末尾。
常见错误现象：
– 每行都得到同一个值（因为没重定义窗口框架）
– 值出现在错误的行上（比如最新记录的字段被复制到旧记录行）
– 分组内多条记录时间相同，LAST_VALUE 随机选一个（无确定性排序）
- 必须显式写
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING才可能覆盖整组 - 必须用
ORDER BY明确变动时间/序号字段，且该字段需能唯一标识“最后”（否则加, id或, created_at DESC做二级排序） -
LAST_VALUE返回的是值，不是整行；要取完整记录，得配合子查询或ROW_NUMBER()
真正可靠的做法：用 ROW_NUMBER() + WHERE = 1
提取“分组内最后一次变动的完整记录”，本质是筛选——不是计算某个字段的值。所以优先用 ROW_NUMBER() 按变动时间倒序编号，再取每组 rn = 1 的行。这是最直观、兼容性最好、行为可预测的方式。
示例（以用户订单变动日志为例，按 updated_at 取每 user_id 最新一条）：
SELECT user_id, order_id, status, updated_at
FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY updated_at DESC, id DESC
) AS rn
FROM order_log
) t
WHERE rn = 1;-
ORDER BY updated_at DESC, id DESC防止时间相同时结果不确定 - 所有主流 SQL 引擎（PostgreSQL、MySQL 8+、SQL Server、Oracle、DuckDB）都支持此写法
- 比
LAST_VALUE更易理解、更易调试、索引友好（如果(user_id, updated_at)有复合索引）
如果非要用 LAST_VALUE，必须配全窗口定义和去重逻辑
硬要用 LAST_VALUE，只能把它当辅助字段用，不能替代行筛选。典型做法是：先用 LAST_VALUE 把“最新变动时间”广播到每行，再用自连接或 WHERE 匹配原表中该时间点的记录——但要注意，这会引入多对一或一对多问题。
安全写法（仅适用于变动时间唯一场景）：
WITH ranked AS (
SELECT *,
LAST_VALUE(updated_at) OVER (
PARTITION BY user_id
ORDER BY updated_at
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
) AS last_updated
FROM order_log
)
SELECT DISTINCT ON (user_id) *
FROM ranked
WHERE updated_at = last_updated
ORDER BY user_id, updated_at DESC;- PostgreSQL 可用
DISTINCT ON快速收口；其他数据库得套一层ROW_NUMBER()再过滤 - 如果同一
user_id有多条记录updated_at完全相同，仍可能漏或多——LAST_VALUE本身不解决“取哪一行”的问题 - 性能通常不如纯
ROW_NUMBER()方案，因窗口扫描两次
容易被忽略的关键点：变动时间字段是否可信？
很多业务表的“最后变动时间”不是由数据库自增或触发器维护，而是应用层写入。这时可能出现：
– 时间字段为空（NULL 被排在最前或最后，取决于 NULLS FIRST/LAST 设置）
– 多个服务时钟不同步，导致时间乱序
– 更新未真正落库（如事务回滚后日志残留）
- 务必在
ORDER BY中处理NULL：ORDER BY updated_at DESC NULLS LAST（PostgreSQL）或用COALESCE(updated_at, '1970-01-01')（通用） - 更稳的做法是加一个严格递增的版本号字段（如
version或log_seq），比时间更可靠 - 如果只有时间字段且不准，
LAST_VALUE和ROW_NUMBER()都会失效——得先修复数据源
