FIRST_VALUE返回的不是“第一笔订单”真实数据，因其默认窗口范围RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW在create_time重复时会随机取值；必须显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，并加唯一排序键（如order_id）确保稳定性，或优先用ROW_NUMBER() + WHERE rn = 1获取完整记录。
为什么 FIRST_VALUE 返回的不是“第一笔订单”的真实数据？
直接用 FIRST_VALUE(order_id) OVER (PARTITION BY user_id ORDER BY create_time)，常会拿到错误结果——不是时间最早那笔，而是按默认排序规则排出来的“第一行”。根本原因在于：窗口函数的 ORDER BY 子句若未显式指定 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（或等效范围），PostgreSQL/Oracle/SQL Server 默认使用该范围，但 MySQL 8.0+ 默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，而 RANGE 在 create_time 有重复值时会把同时间的所有行视作同一组，导致 FIRST_VALUE 随机取其中一行。
- 必须显式写
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING才能确保“全组内最早”（注意：不是当前行到开头，而是整个分组） - 更稳妥的做法是：先用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time, order_id)标记序号，再用WHERE rn = 1过滤——语义清晰、行为确定、所有数据库一致 -
FIRST_VALUE是窗口函数，不能直接在WHERE或GROUP BY中过滤；它只生成列，不改变行数
怎样用 FIRST_VALUE 安全获取完整订单详情字段？
想拿“每个用户第一笔订单的 order_id、amount、status”，不能对每个字段都套一遍 FIRST_VALUE 并假设它们来自同一行——因为窗口定义稍有不同（比如 ORDER BY 字段顺序、NULL 处理），就可能错位。正确做法是：用子查询或 CTE 先算出“第一笔订单的主键”，再关联原表。
- 推荐写法（兼容性强）：
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time, order_id) AS rn FROM orders ) SELECT o.* FROM orders o INNER JOIN (SELECT user_id, order_id FROM ranked WHERE rn = 1) first ON o.order_id = first.order_id; - 如果坚持用
FIRST_VALUE，必须对所有要取的字段用完全相同的窗口定义：FIRST_VALUE(order_id) OVER w、FIRST_VALUE(amount) OVER w，且w必须是命名窗口（WINDOW w AS (PARTITION BY user_id ORDER BY create_time, order_id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)） - 注意
NULL值：若create_time可为空，ORDER BY create_time默认把NULL排最前（MySQL/PostgreSQL），可能误选空时间的脏数据；建议加WHERE create_time IS NOT NULL预过滤
FIRST_VALUE 和 MIN() / MAX() 的本质区别在哪？
MIN(create_time) 只能返回时间值，无法带回同一行的 order_id 或 amount；而 FIRST_VALUE 是基于排序位置取值，不关心字段是否聚合。但这也带来陷阱：
-
FIRST_VALUE(amount) OVER (PARTITION BY user_id ORDER BY create_time)取的是排序后第一行的amount，不是该用户所有订单里金额最小的那个——别和聚合函数混淆 - 如果业务上真要“每个用户金额最低的那笔订单详情”，得用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount, create_time)，而不是靠FIRST_VALUE+MIN(amount) -
FIRST_VALUE性能通常比子查询略好（尤其大数据量），但可读性和可维护性差；调试时很难验证它是否真取到了你认为的“第一笔”
MySQL 8.0 下 FIRST_VALUE 的一个典型报错：Window 'w' requires an ORDER BY clause
MySQL 强制要求所有命名窗口（WINDOW w AS (...)）或匿名窗口必须带 ORDER BY，哪怕你只想取分组内任意一行。这时候不能写 ORDER BY NULL（语法错误），也不能省略。
- 正确绕过方式：用常量排序，如
ORDER BY 1（但注意这不保证稳定，因无真实排序依据） - 真正需要“任意一行”时，应改用
GROUP BY user_id+ANY_VALUE(order_id)（MySQL 特有，5.7+ 开启sql_mode不含ONLY_FULL_GROUP_BY） - 若必须用
FIRST_VALUE且不想排序，可伪造一个唯一序号：ORDER BY (SELECT 1)不合法，但ORDER BY user_id*0合法（仍不推荐，语义不清）
实际业务中，“第一笔订单”往往隐含严格的时间先后与唯一性约束，ROW_NUMBER() + 子查询仍是首选。用 FIRST_VALUE 的时候，多一眼确认窗口范围和排序字段是否真的覆盖了所有歧义点。
