FIRST_VALUE()在重复时间戳下可能返回意外值，因其严格依赖ORDER BY逻辑顺序而非物理顺序；当created_at相同且无二级排序字段（如id）时，数据库对并列行的相对顺序不保证，导致结果不稳定。
为什么FIRST_VALUE()在重复时间戳下可能返回“意外”的值？
FIRST_VALUE() 不是按“物理插入顺序”取值，而是严格依赖 ORDER BY 子句定义的逻辑顺序。当多个行具有相同时间戳（比如 created_at = '2024-05-01 10:00:00'），而你只按该字段排序，SQL 标准不保证这些行之间的相对顺序 —— 数据库可能任意排列它们，导致 FIRST_VALUE() 每次执行结果不一致（尤其在 PostgreSQL、SQL Server 中较明显）。
- 根本原因：缺乏确定性排序键（tie-breaker）
- 典型现象：同一查询多次运行，
FIRST_VALUE(name)返回不同name - 不是 bug，是标准行为 —— 你需要显式补全排序依据
必须加一个唯一排序字段来稳定FIRST_VALUE()结果
最可靠的做法是在 ORDER BY 中追加一个能打破并列的列，例如主键 id 或自增序列字段。这样即使时间戳相同，也能保证每次排序结果一致。
SELECT
id,
created_at,
name,
FIRST_VALUE(name) OVER (
ORDER BY created_at, id -- ✅ 关键：用 id 确保相同时间戳下的确定顺序
) AS first_name_by_time
FROM events;- 优先选
id（如果是整型主键）或row_number() OVER (ORDER BY id)生成的序号 - 避免用
name或其他可能重复的业务字段作第二排序键 - 如果真没可用唯一字段，可临时加
ROW_NUMBER() OVER (ORDER BY created_at, RANDOM())（PostgreSQL）或NEWID()（SQL Server），但仅用于调试，不可用于生产逻辑
窗口框架（ROWS/RANGE）对FIRST_VALUE()有实际影响吗？
有，而且容易被忽略。默认情况下 FIRST_VALUE() 使用 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，这在重复时间戳场景下会扩大“当前行组”范围 —— 所有同时间戳的行会被视为同一组，FIRST_VALUE() 可能从“后面”的同时间戳行中取值（取决于排序稳定性）。
- 明确写成
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING更符合直觉（全窗口找第一个） - 但更推荐保持默认 + 补唯一排序，而不是靠改框架去“绕开”问题
- 若用
RANGE且时间戳为TIMESTAMP类型，注意毫秒精度是否被截断（如 MySQL 的DATETIME默认无毫秒），会导致更多隐式并列
替代方案：用DISTINCT ON（PostgreSQL）或LATERAL JOIN更直观？
如果你只是想“每个时间戳取第一条记录”，FIRST_VALUE() 其实是过度设计。直接用 DISTINCT ON 更清晰、性能更好：
-- PostgreSQL 专用，语义明确：每个 created_at 取 id 最小的那行 SELECT DISTINCT ON (created_at) * FROM events ORDER BY created_at, id;
- MySQL 用户可用
ROW_NUMBER() OVER (PARTITION BY created_at ORDER BY id)+ 外层过滤rn = 1 - SQL Server 同理，但注意
PARTITION BY对空值的处理（NULL会被归为同一组） -
FIRST_VALUE()适合需要“在每行上都显示首个值”的场景；若只需聚合后取一行，别硬套窗口函数
真正麻烦的不是语法，而是默认排序没有唯一性约束时，数据库根本不会提醒你结果不可靠 —— 它安静地返回某个值，而你直到上线后查数据异常才意识到问题。
