LAST_VALUE默认取不到分组末尾值，因其窗口帧默认为RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，仅覆盖当前行及之前行，故返回当前行值；必须显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING才能覆盖整组，并配合确定性ORDER BY（如time_col DESC, id DESC）及索引优化确保结果准确稳定。
LAST_VALUE 为什么默认取不到分组末尾值？
直接写 LAST_VALUE(column) OVER (PARTITION BY group_col ORDER BY time_col) 很可能返回当前行的值，而不是你想要的“分组内最后一行的值”。这是因为窗口帧默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW —— 它只看从开头到当前行为止的数据，LAST_VALUE 自然只能看到“已扫过的最后一条”，不是整个分组的最后一条。
必须显式改写窗口帧范围：
- 用
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING才能覆盖整组 -
RANGE在涉及重复排序值时行为不稳定，优先选ROWS - 如果排序列有
NULL，注意ORDER BY默认把NULL排最前（不同数据库略有差异），必要时加NULLS LAST
如何确保取到真正“最后一条记录”的完整行？
LAST_VALUE() 只能返回单个字段值，没法直接拿到整行。想拿到完整记录（比如 id、name、status 全部），得换思路：用窗口函数标出每组“最后一条”的序号，再过滤。
典型做法是配合 ROW_NUMBER() 或 RANK()：
- 按分组 + 时间倒序排：
ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY time_col DESC, id DESC) - 取序号为 1 的行：
WHERE rn = 1 - 如果时间相同要保多条，用
RANK()；严格只取一条（哪怕时间并列）用ROW_NUMBER()
示例片段：
SELECT id, name, status, group_col
FROM (
SELECT id, name, status, group_col,
ROW_NUMBER() OVER (
PARTITION BY group_col
ORDER BY updated_at DESC, id DESC
) AS rn
FROM orders
) t
WHERE rn = 1;
MySQL 8.0+ 和 PostgreSQL 的 LAST_VALUE 行为差异
MySQL 8.0+ 支持 LAST_VALUE，但默认帧和 PostgreSQL 一致，同样需要手动指定 ROWS 范围；PostgreSQL 还支持 IGNORE NULLS 参数（MySQL 不支持）。
- PostgreSQL 可写：
LAST_VALUE(val) IGNORE NULLS OVER (...) - MySQL 遇到
NULL会中断连续性，需提前用COALESCE或子查询清理 - SQLite 目前（3.45）仍不支持
LAST_VALUE，只能用MAX()+ 关联或子查询模拟
性能要注意：ORDER BY 列必须有索引
窗口函数依赖排序，而 PARTITION BY + ORDER BY 组合如果没有对应索引，容易触发临时文件排序，大数据量下响应明显变慢。
- 理想索引：
(group_col, time_col DESC)（注意方向匹配ORDER BY） - 如果还涉及
WHERE条件，考虑复合索引包含过滤字段，比如(status, group_col, time_col DESC) - 执行计划里留意是否出现
Using temporary; Using filesort
真正麻烦的不是语法写对，而是排序字段没索引时，LAST_VALUE 看似简洁，实际比子查询还慢。
