first_value必须配合over子句使用，且order by为强制要求，用于定义分组内排序依据；partition by划分组边界，默认窗口框架适用；mysql与postgresql在null处理上存在差异；取整行数据应优先用row_number()而非多个first_value。
FIRST_VALUE函数的基本用法和窗口定义
FIRST_VALUE 是一个窗口函数，它不会自动按分组取首行——必须配合 OVER 子句明确定义窗口范围。没写 ORDER BY 会导致结果不确定，即使你只想要“第一条”，数据库也不会按插入顺序返回。
常见错误是直接写 FIRST_VALUE(col) OVER (PARTITION BY group_col)，这会报错或返回任意值（取决于数据库实现）。必须指定排序依据：
-
ORDER BY是强制要求项，哪怕你只关心“物理第一行”，也得选一个稳定字段（如时间戳、自增ID）来模拟 -
PARTITION BY定义分组边界，不写就变成全表窗口，失去“分组内”的语义 - 默认窗口框架是
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，对FIRST_VALUE来说够用，一般不用改
MySQL 8.0+ 和 PostgreSQL 中的写法差异
语法一致，但行为细节不同：PostgreSQL 默认允许 NULLS FIRST/LAST 控制空值位置；MySQL 8.0 不支持该子句，NULL 总排在最前（升序时）。
示例（获取每个部门薪资最高的员工姓名）：
SELECT dept, name, salary,
FIRST_VALUE(name) OVER (PARTITION BY dept ORDER BY salary DESC) AS top_earner
FROM employees;
注意：ORDER BY salary DESC 才能拿到最高薪者；若写 ASC，得到的是最低薪者——FIRST_VALUE 取的是排序后第一行，不是原始数据第一行。
替代方案：当 FIRST_VALUE 不适用时怎么办？
如果你实际想“取分组中某条件成立的第一条记录整行”，FIRST_VALUE 只能提取单个字段，无法带回其他列（比如同时要姓名、入职日期、岗位）。这时容易踩坑：
- 用多个
FIRST_VALUE分别取不同列，但排序依据不一致（比如一个按时间、一个按ID），会导致字段来自不同行 - 误以为
FIRST_VALUE能替代子查询或ROW_NUMBER()，但它不提供行号，无法做WHERE rn = 1过滤
更稳妥的做法是用 ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...) 生成序号，再外层过滤 rn = 1，这样能完整保留整行数据。
性能与 NULL 处理的隐性成本
FIRST_VALUE 在大数据量下会触发完整窗口扫描，尤其当 PARTITION BY 组数多、每组数据大时，内存和 CPU 开销明显高于普通聚合。
关于 NULL：
- 如果排序字段有
NULL，且未显式控制NULLS FIRST/LAST（PostgreSQL 支持，MySQL 不支持），结果可能不符合预期 -
FIRST_VALUE返回NULL本身是合法值，不会跳过——如果首行就是NULL，就真返回NULL - 想跳过
NULL取第一个非空值？标准 SQL 没内置支持，得用CASE WHEN+ROW_NUMBER组合实现
真正麻烦的不是语法，而是想清楚：“首条”到底指什么——是时间最早？ID 最小？还是业务上定义的优先级顺序？这个逻辑一旦定错，FIRST_VALUE 会忠实地放大错误。
