FIRST_VALUE常取不到预期首行，因其默认窗口帧仅覆盖当前行及之前行，且未显式ORDER BY时排序无保证；必须用PARTITION BY配合ORDER BY（如created_at, id）确保稳定性。
FIRST_VALUE 为什么经常取不到预期的第一行
因为 FIRST_VALUE 默认按当前窗口帧（frame）计算，而未显式声明 ORDER BY 时，SQL 标准不保证行序 —— 实际结果取决于执行引擎的物理扫描顺序，可能每次查询都不一样。哪怕加了 GROUP BY，它本身不控制窗口内排序，FIRST_VALUE 依然无法稳定定位“第一行”。
必须配合 ORDER BY 子句在 OVER() 中显式指定排序依据，否则所谓“第一行”只是偶然。
-
FIRST_VALUE(col) OVER (PARTITION BY group_col ORDER BY sort_col)才是安全写法 - 若想按插入顺序取首行，需确保表中存在可排序的时间戳字段（如
created_at）或自增 ID - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持该用法；SQLite 仅部分版本支持
分区后取“最早创建时间对应整行数据”怎么写
单纯用 FIRST_VALUE 只能取单列值，无法直接拿到整行。常见错误是套多层子查询或误用 ROW_NUMBER() 却没过滤 rn = 1。
推荐做法：用 ROW_NUMBER() OVER (PARTITION BY ... ORDER BY created_at) 生成序号，外层筛选 rn = 1。比嵌套 FIRST_VALUE 多次更清晰、更易扩展。
SELECT *
FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY dept_id
ORDER BY created_at ASC
) AS rn
FROM employees
) t
WHERE rn = 1;- 不能用
FIRST_VALUE(id) OVER (...) = id这类逻辑做行过滤——窗口函数不能出现在WHERE中 - 如果存在并列（多个相同
created_at），ROW_NUMBER()会任意分配序号；需加二级排序（如id）保证确定性 -
RANK()或DENSE_RANK()不适用此场景，它们会给并列值同序号，导致多行被保留
ORDER BY 用表达式或函数会影响 FIRST_VALUE 稳定性吗
会影响。只要 ORDER BY 表达式结果不唯一，FIRST_VALUE 就可能在不同执行中返回不同行 —— 即使看起来“应该”固定。
例如：ORDER BY EXTRACT(YEAR FROM hire_date) 在同一组内有多个员工入职年份相同时，数据库无义务保持一致顺序。
- 稳定性关键：排序键组合必须在每个分区内具有唯一性，或至少加上一个隐式唯一列（如主键）作为兜底
- 安全写法示例：
ORDER BY hire_date, employee_id - 避免使用
ORDER BY RANDOM()或ORDER BY some_col + 0这类无意义扰动 - PostgreSQL 中若用
ORDER BY text_col COLLATE "C"可提升跨环境一致性，但本质仍是靠排序键唯一性
MySQL 5.7 不支持窗口函数，有没有替代方案
没有原生等价写法。FIRST_VALUE 是窗口函数，MySQL 5.7 完全不识别 OVER 语法，强行写会报错 ERROR 1064 (42000): You have an error in your SQL syntax。
可行替代路径只有两种：
- 升级到 MySQL 8.0+（最直接）
- 用相关子查询模拟，性能差且语法冗长：
(SELECT t2.name FROM employees t2 WHERE t2.dept_id = t1.dept_id ORDER BY t2.created_at LIMIT 1) - 应用层聚合：查出全部数据，在代码里按
dept_id分组后取每组排序首项（适合数据量小、实时性要求不高的场景）
别试图用变量（@prev := ...）模拟窗口函数——在 MySQL 5.7 中变量赋值顺序不保证，尤其在 ORDER BY 和 GROUP BY 共存时极易出错。
