last_value不能直接取分组内满足条件的最后一条记录，因其默认窗口帧为rows between unbounded preceding and current row，仅覆盖当前行及之前行；需显式指定unbounded following并配合确定性排序，但更可靠的做法是用row_number()配合条件过滤后取rn=1。
LAST_VALUE 真的不能直接“取分组内满足条件的最后一条”
LAST_VALUE 是窗口函数，但它默认行为是“在当前窗口帧（frame）内取最后一个值”，不是“取整个分组里满足某条件的那条记录”。很多人一上来就写 LAST_VALUE(col) OVER (PARTITION BY group_col ORDER BY time_col)，结果发现返回的经常是重复值、NULL，或者根本不是想要的那条——因为没指定 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，默认帧是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，导致 CURRENT ROW 位置永远“看不到后面”的行。
- 默认帧下，
LAST_VALUE(x)在排序后每一行都只看从开头到自己这行，所以最后一行才真正拿到“组内最大时间对应值”，前面所有行都只是局部末尾 - 加
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING后，LAST_VALUE才真正在整组里找最后一个，但前提是：你得先确保排序键能唯一标识“最后”的语义（比如created_at DESC），且该列无 NULL - 如果要“满足条件的最后一条”，比如
status = 'done'的最后一条，LAST_VALUE本身不支持 where 过滤窗口内行——它只能对已排序的完整窗口起作用
更可靠的做法：用子查询 + ROW_NUMBER() 模拟“条件内最后一条”
比起硬套 LAST_VALUE，用 ROW_NUMBER() 配合条件过滤再取 rn = 1 更直观、可控，也兼容所有主流 SQL 引擎（PostgreSQL、SQL Server、MySQL 8.0+、Oracle）。
- 先用
ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY filter_time DESC)给每组内满足条件的记录编号，注意ORDER BY必须含确定性排序（比如加id DESC防止时间相同时序不确定） - 外层只
WHERE status = 'done' AND rn = 1，这样每组最多一条，且一定是满足status = 'done'中时间最晚的那条 - 别在窗口函数里写
WHERE status = 'done'—— 窗口计算发生在 WHERE 之前，必须把过滤移到外层或 CTE 中
示例：
WITH ranked AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY updated_at DESC, id DESC
) AS rn
FROM orders
WHERE status = 'done'
)
SELECT user_id, order_id, updated_at
FROM ranked
WHERE rn = 1;
MySQL 8.0+ 或 PostgreSQL 可用 LATERAL / JOIN LATERAL 简化关联场景
当你要查每个用户“最后一次完成订单”的同时，还想带出该订单的关联信息（如商品列表、日志），用 ROW_NUMBER() 子查询可能需多次 JOIN。这时用 LATERAL（PostgreSQL）或 JOIN ... ON TRUE + 相关子查询（MySQL）更干净。
- PostgreSQL 示例：
SELECT u.name, o.order_id FROM users u LEFT JOIN LATERAL (SELECT * FROM orders WHERE user_id = u.id AND status = 'done' ORDER BY updated_at DESC LIMIT 1) o ON true - MySQL 8.0+ 不支持
LATERAL，但可用相关标量子查询：(SELECT order_id FROM orders o2 WHERE o2.user_id = u.id AND o2.status = 'done' ORDER BY o2.updated_at DESC LIMIT 1)作为字段 - 注意：这类写法在大表上可能比窗口函数慢，因为每组都触发一次索引查找；确保
(user_id, status, updated_at)有联合索引
LAST_VALUE 能用但要非常小心的两个边界情况
如果你坚持用 LAST_VALUE，以下两点不处理就会出错：
-
NULL值干扰：如果排序字段（如updated_at）有 NULL，LAST_VALUE默认把这些行排在最前（NULLS FIRST），导致“最后一条”实际是 NULL 行。显式写ORDER BY updated_at DESC NULLS LAST（PostgreSQL/Oracle）或在 MySQL 中用IFNULL(updated_at, '1970-01-01')替换 - 去重逻辑缺失：若多条记录时间完全相同，
LAST_VALUE会任选其一返回（非确定性），而ROW_NUMBER()可靠地通过二级排序（如id DESC）打破平局 - 性能差异：
LAST_VALUE(... RANGE UNBOUNDED)在某些引擎中无法利用索引加速，而ROW_NUMBER()+WHERE rn=1更容易被优化器识别为 Top-N 查询
真正需要“分组内满足条件的最后一条”时，ROW_NUMBER() 是事实标准。LAST_VALUE 更适合做“滚动末位填充”这类报表场景，而不是业务主键级的数据选取。
