last_value默认拿不到分组末尾值，因其窗口帧为rows between unbounded preceding and current row，仅覆盖当前行及之前行；必须显式指定rows between unbounded preceding and unbounded following，并配合确定性order by（如时间降序+二级排序）才能正确获取分组末值。
LAST_VALUE 为什么默认拿不到分组末尾值
直接写 LAST_VALUE(col) OVER (PARTITION BY group_col ORDER BY time_col) 很可能返回当前行的值，而不是分组内“最后一条”。这是因为窗口帧默认是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW —— 它只看当前行及之前，根本没包含后面的记录。
要拿到真正的末尾值，必须显式改写帧范围。常见错误是只加 ORDER BY 却忽略 ROWS 或 RANGE 子句。
- PostgreSQL / SQL Server / Oracle：用
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING - MySQL 8.0+：同上，但注意它不支持
RANGE与UNBOUNDED FOLLOWING混用时的某些边界行为 - SQLite：不支持
LAST_VALUE（需用子查询或ROW_NUMBER()替代）
正确写法：指定完整窗口帧 + 处理 NULL
LAST_VALUE 在帧内最后一行有值时才返回它；如果末尾行该列是 NULL，结果就是 NULL，且不会自动向前找非空值。这和你直觉里的“最后一个非空值”不同。
实操建议：
- 强制指定帧：
LAST_VALUE(val) OVER (PARTITION BY grp ORDER BY ts ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) - 防 NULL：外层套
COALESCE(LAST_VALUE(...), ...)，或改用FIRST_VALUE配合倒序ORDER BY ts DESC - 若只要整行（不止一列），
LAST_VALUE不适用 —— 改用ROW_NUMBER() OVER (... ORDER BY ts DESC) = 1过滤
示例（获取每组按时间排序的最后一条 name）：
SELECT
id, grp, ts, name,
LAST_VALUE(name) OVER (
PARTITION BY grp
ORDER BY ts
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
) AS last_name_in_group
FROM events;
替代方案：什么时候不该硬用 LAST_VALUE
当目标只是“取每组最新完整记录”，LAST_VALUE 是绕路的。它只能逐列计算，无法天然带回整行其他字段，还容易因排序字段重复导致不确定性。
更稳的路径：
- 用
ROW_NUMBER() OVER (PARTITION BY grp ORDER BY ts DESC)然后WHERE rn = 1 - 用关联子查询：
WHERE ts = (SELECT MAX(ts) FROM t2 WHERE t2.grp = t1.grp)（注意多值冲突） - 在 PostgreSQL 中可用
DISTINCT ON (grp) ORDER BY grp, ts DESC
性能上，LAST_VALUE 需扫描整个窗口，而 ROW_NUMBER + 过滤通常能更好利用索引（尤其 grp, ts 复合索引）。
ORDER BY 字段重复时的陷阱
如果 ORDER BY 的字段（如时间戳）存在重复，LAST_VALUE 的结果不可靠 —— 窗口帧里“最后”是未定义的，数据库可能任意选一个。
必须补唯一性保证：
- 追加主键或唯一列进
ORDER BY，例如ORDER BY ts DESC, id DESC - 避免仅用
ORDER BY status这类低基数字段做排序依据 - 测试时用
COUNT(*) OVER (PARTITION BY grp ORDER BY ts ROWS UNBOUNDED PRECEDING)观察帧内行数是否突变
真正难的不是写对语法，而是确认业务上“最后”有没有明确定义 —— 时间相同算并列？谁优先？这个逻辑一旦模糊，窗口函数只会忠实地放大歧义。
