ROW_NUMBER()需配合PARTITION BY user_id与ORDER BY event_time（ASC/DESC）标记首末行，注意NULL及同秒排序稳定性；FIRST_VALUE/LAST_VALUE须显式指定UNBOUNDED PRECEDING TO UNBOUNDED FOLLOWING窗口帧；条件聚合+MAX(CASE WHEN)是合并首末行为到单行的可靠方法。
用 ROW_NUMBER() 标记首次和末次行为
窗口函数本身不直接返回“首次”或“末次”的值，但可以用 ROW_NUMBER() 按时间排序后取序号为 1 的行。关键在于分区与排序逻辑：按用户分组（PARTITION BY user_id），再按行为时间升序（首次）或降序（末次）排序。
常见错误是忽略 NULL 时间值导致排序错位，或未明确指定 ORDER BY 中的二级排序（比如同秒内多条行为时结果不稳定）。建议在 ORDER BY event_time 后追加 event_id 等唯一字段保序：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time ASC, event_id ASC) AS rn_first
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time DESC, event_id DESC) AS rn_last
用 FIRST_VALUE() 和 LAST_VALUE() 直接取值
这两个函数更贴近“取首次/末次行为字段”的直觉需求，但必须注意默认窗口帧（ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW）会让 LAST_VALUE() 只看到当前行及之前——它不会自然返回组内最后一行的值。
正确写法需显式声明完整窗口范围：
FIRST_VALUE(event_type) OVER (PARTITION BY user_id ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS first_event
LAST_VALUE(event_type) OVER (PARTITION BY user_id ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS last_event
若只关心时间字段，MIN(event_time) 和 MAX(event_time) 更简洁且无帧陷阱，但无法附带关联字段（如对应的行为类型）。
合并首次与末次行为到同一行输出
多数场景需要把每个用户的首次行为时间、类型和末次行为时间、类型放在一行里，不能靠单个窗口函数一步到位。得先用子查询或 CTE 标出标记，再聚合。
推荐做法是：用 ROW_NUMBER() 打标后，在外层用条件聚合（CASE WHEN rn_first = 1 THEN ... END）提取字段：
SELECT
user_id,
MAX(CASE WHEN rn_first = 1 THEN event_time END) AS first_time,
MAX(CASE WHEN rn_first = 1 THEN event_type END) AS first_type,
MAX(CASE WHEN rn_last = 1 THEN event_time END) AS last_time,
MAX(CASE WHEN rn_last = 1 THEN event_type END) AS last_type
FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time ASC) AS rn_first,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time DESC) AS rn_last
FROM events
) t
GROUP BY user_id;
注意：这里用 MAX() 是因为每组只有一个非 NULL 值，本质是取值而非真求最大；若用 MIN() 效果一样，但语义不如 MAX 清晰（毕竟我们没在比大小）。
性能与兼容性提醒
FIRST_VALUE() / LAST_VALUE() 在 PostgreSQL、SQL Server、Oracle、Trino 中行为一致，但在 MySQL 8.0+ 才支持，且旧版 Hive 不支持完整 ROWS 子句；ROW_NUMBER() 兼容性更好。
大数据量下，PARTITION BY user_id ORDER BY event_time 的排序开销不可忽视。如果表已有 (user_id, event_time) 复合索引，能显著加速窗口计算——否则可能触发全局排序，拖慢查询数倍。
真正容易被忽略的是行为时间精度：如果原始字段是 DATETIME 但业务上“同秒即视为同时”，那排序时仅用 event_time 可能导致首次/末次判定随机。此时应提前截断或增加确定性排序键。
