MySQL 8.0中FIRST_VALUE必须配合OVER()子句使用，不可独立调用；需指定PARTITION BY和ORDER BY（如created_at, id）确保结果确定性，否则报语法错误且结果不可控。
MySQL 8.0中FIRST_VALUE必须搭配窗口函数语法使用
直接写 FIRST_VALUE(status) 会报错，因为 MySQL 8.0 不支持独立聚合式调用 —— 它严格要求配合 OVER() 子句定义窗口范围。没加 OVER 就像调用一个没传参的函数，MySQL 直接拒绝执行。
常见错误现象：ERROR 1064 (42000): You have an error in your SQL syntax，往往卡在 FIRST_VALUE 后面的括号位置，实际是缺 OVER。
- 必须显式指定分区（
PARTITION BY group_id）和排序（ORDER BY created_at），否则结果不可控 - 不写
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW也没问题，默认就是这个范围，但别误以为可以省略OVER整体 - 如果业务上“首个”由时间决定，
ORDER BY必须包含确定性字段（如created_at, id），避免同秒插入导致排序随机
获取分组内按时间最早的状态值
典型场景：每个订单（order_id）有多条状态变更记录，要取第一条（即最早创建）的 status 值作为“初始状态”。
正确写法示例：
SELECT
order_id,
status,
created_at,
FIRST_VALUE(status) OVER (
PARTITION BY order_id
ORDER BY created_at, id
) AS first_status
FROM order_status_log;
注意点：
-
ORDER BY created_at, id中补id是防重复时间戳，否则同一秒多条记录时FIRST_VALUE可能返回任意一条（MySQL 不保证稳定顺序） - 若只要“每个分组一行结果”，不能只靠
FIRST_VALUE，还得配合GROUP BY或去重逻辑；它本身是行级计算，原表多少行，结果就多少行 - 性能上，
PARTITION BY + ORDER BY会触发临时窗口排序，大表务必确保(order_id, created_at, id)有联合索引
FIRST_VALUE和MIN/MAX在语义上的关键区别
有人想用 MIN(status) 替代，这是危险的 —— status 通常是字符串（如 'pending', 'shipped'），MIN() 返回的是字典序最小值，不是时间上第一个。
例如分组内状态变更顺序是：'pending' → 'confirmed' → 'shipped'，MIN(status) 返回 'confirmed'（c 在 p 和 s 前），但你要的是 'pending'。
-
FIRST_VALUE看的是ORDER BY定义的物理顺序，MIN/MAX看的是值本身的大小关系 - 即使
status是数字编码（如 1,2,3），只要业务含义是“按时间先后”，仍得用FIRST_VALUE，不能依赖数值大小 - 没有
ORDER BY的FIRST_VALUE语法不合法，而MIN即使不加GROUP BY也能运行（但结果无意义）
需要去重时别只依赖FIRST_VALUE
如果目标是“每个分组只返回一行 + 首个状态”，FIRST_VALUE 自身做不到，它只是新增一列。你得组合其他手段：
- 用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at, id) = 1过滤出首行 - 或在外层用
GROUP BY order_id配合MIN(created_at)关联回原表取对应status（需自连接或子查询） - 别试图用
SELECT DISTINCT order_id, FIRST_VALUE(status) OVER (...)——DISTINCT对窗口函数列无效，仍会返回多行
真正容易被忽略的是：FIRST_VALUE 的结果稳定性完全绑定在 ORDER BY 表达式的确定性上。哪怕只是少写了 id 导致同时间戳记录排序浮动，线上就可能每天跑出不同“首个状态”。
