FIRST_VALUE() 默认拿不到分组第一行，因其窗口帧为RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，仅覆盖分区开头至当前行；需显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING并确保ORDER BY稳定。
为什么 FIRST_VALUE() 拿不到分组第一行？
因为默认窗口帧是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ，不是整组。哪怕你写了 PARTITION BY user_id ，它也只从分区开头算到当前行，导致中间行的 FIRST_VALUE() 返回的是“到当前位置为止”的第一个值，而非整个分组的第一行。
实操建议：
- 必须显式指定窗口帧为
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING - 同时确保
ORDER BY有明确、稳定的排序依据（比如带时间戳或唯一 ID），否则“第一行”结果不可靠 - 如果只是想取分组固定首尾（不依赖排序），
FIRST_VALUE()不是最佳选择——考虑用子查询或JOIN配合GROUP BY+MIN()/MAX()更稳妥
LAST_VALUE() 总返回当前行？
这是最常踩的坑： LAST_VALUE() 在默认窗口帧下，等价于“当前行的值”，因为它只看到从开头到当前行的数据，当前行自然就是“最后”。它不像 FIRST_VALUE() 那样有“直觉上的首”， LAST_VALUE() 必须配合完整帧才能生效。
实操建议：
- 强制写全帧：
LAST_VALUE(col) OVER (PARTITION BY x ORDER BY y ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) - 注意
ORDER BY的语义：按时间升序时，LAST_VALUE()取的是最新一条；按降序则取最早一条——别光看函数名，要看排序方向 - 某些旧版 Hive 或 Spark SQL 对
UNBOUNDED FOLLOWING支持不一致，测试时务必验证边界数据（如单行分组）
PostgreSQL / MySQL 8.0+ 中的兼容性差异
MySQL 8.0+ 和 PostgreSQL 都支持标准语法，但默认行为一致不代表实际表现一致。关键是排序字段存在重复值时，不同引擎对“相等行的相对顺序”处理不同，可能让 FIRST_VALUE() 指向非预期行。
实操建议：
- 在
ORDER BY中加入唯一列兜底，例如：ORDER BY created_at, id - PostgreSQL 允许用
NULLS FIRST/LAST显式控制空值位置；MySQL 8.0 不支持该子句，空值默认排最前，需提前COALESCE()处理 - MySQL 中若
ORDER BY字段全为NULL，FIRST_VALUE()可能随机返回某一行——这不是 bug，是未定义行为
替代方案：不用窗口函数也能取首尾，什么时候更合适？
当逻辑简单、数据量不大、或需要兼容老版本数据库（如 MySQL 5.7）时，硬上窗口函数反而增加复杂度和出错概率。
实操建议：
- 取分组首条记录（按时间）：
SELECT * FROM t1 INNER JOIN (SELECT user_id, MIN(created_at) AS min_t FROM t1 GROUP BY user_id) t2 ON t1.user_id = t2.user_id AND t1.created_at = t2.min_t - 取分组最新一条（避免多条同时间）：加
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC) = 1过滤，比LAST_VALUE()更可控 - 如果只是聚合后展示首尾值（非逐行输出），直接用
ARRAY_AGG(col ORDER BY t)[1]（PostgreSQL）或JSON_EXTRACT(MIN(JSON_OBJECT(t,col)), '$.col')（MySQL）更轻量
真正麻烦的从来不是写对那行 FIRST_VALUE() ，而是没意识到“分组首尾”本身隐含了排序稳定性、重复值处理、以及执行引擎对窗口边界的实现差异。这些点不提前对齐，查出来的数看着对，换条数据就翻车。
