先直接给出结论：LAST_VALUE 并不是获取分组“最后一条记录”的可靠方法。许多开发者被它的字面含义误导，以为使用 LAST_VALUE(column) 就能得到每组最后一条数据，结果发现中间行的返回值与预期完全不同。问题根源在于其默认的窗口帧——RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，这意味着每一行只能看到从分区起始到当前行为止的数据。因此，只有最后一行才能获取真正的“最后值”，其他行得到的只是截至当前行的局部最后值，而非整个分组的最终结果。
举例说明：假设按时间升序排序，中间行的 LAST_VALUE(status) 显示的是“到这一行时刻为止的最新状态”，而非整个组的最终状态。即便将帧改为 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，也只能确保每一行看到全组数据，但如果排序键存在重复（如两个订单创建时间相同），结果就会变得不确定——数据库可能随机返回其中一个值。更关键的是，LAST_VALUE 不会减少行数，它只是为每行附加一个值，因此无法直接用它“筛选出最后一条记录”。
为什么 LAST_VALUE 默认行为不符合“取最后一条记录”的直觉？
SQL 中的 LAST_VALUE 是一个窗口函数，其输出结果高度依赖 OVER() 子句中的 ORDER BY 和帧定义（ROWS 或 RANGE）。默认帧为 UNBOUNDED PRECEDING TO CURRENT ROW，即对每一行，它只考虑从分区开头到当前行的数据——因此只有最后一行才能得到真正的“最后值”，其余行得到的只是截至当前行的局部最后值。
- 若按时间升序排序，
LAST_VALUE(col)在中间行返回的是“到此刻为止的最大/最新值”，而不是整组的最终值 - 即便加上
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，重复排序键仍可能导致非确定性结果 - 它不改变行数，只是为每行附加一个值，无法直接“筛选出最后一条记录”
真正想取每组最后一条原始记录，该用什么？
经典方案是：使用 ROW_NUMBER() 配合子查询或 CTE，按业务逻辑定义“最后”的排序顺序（通常按时间倒序、ID 倒序），然后在外层通过 WHERE rn = 1 筛选出来。
- 根据业务定义“最后”：通常是时间字段最大、ID 最大或插入顺序最晚 → 使用
ORDER BY created_at DESC或id DESC - 用
ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY created_at DESC)为每组内的每一行编号 - 外层
WHERE rn = 1筛选出每组排第一的那条（即“最后一条”） - 注意：若存在并列（如相同
created_at），ROW_NUMBER()会保证只选一条；RANK()可能返回多条，需根据业务场景决定是否接受
示例：
SELECT id, user_id, status, created_at
FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC) AS rn
FROM orders
) t
WHERE rn = 1;
LAST_VALUE 什么时候可以凑合用？
仅当你不需要删除行，只希望将“每组最后的某个字段值”广播到本组所有行上时，LAST_VALUE 才有实用价值，且必须显式指定帧：
- 正确写法：
LAST_VALUE(col) OVER (PARTITION BY group_col ORDER BY sort_col ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) - 必须确保
ORDER BY列组合能唯一确定顺序，否则重复值会导致LAST_VALUE返回任意一个（无保证） - 性能上通常比
ROW_NUMBER()+ 过滤略差，因为要计算全帧，且结果仍是多行
例如：给每个订单补充该用户最新订单的 status：
SELECT id, user_id,
LAST_VALUE(status) OVER (
PARTITION BY user_id
ORDER BY created_at, id
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
) AS latest_status
FROM orders;
如果目标是“取最后一条记录”，不必绕弯路使用 LAST_VALUE，ROW_NUMBER() + WHERE rn = 1 是最直接、可读且可控的方案。一个容易被忽视的关键点是排序键的唯一性——如果 ORDER BY 字段存在重复，务必补充一个确定性次序字段（比如主键 id），否则结果不可预期。
