FIRST_VALUE不能直接回填主键，因其仅传播窗口内已有值，无法生成或推断缺失主键；仅当同组内存在非空主键时，配合IGNORE NULLS或LAG/LEAD组合才可伪回填。
为什么FIRST_VALUE不能直接回填主键维度
FIRST_VALUE 是窗口函数，作用是在一个分组内取排序后第一行的值，但它不会修改原表数据，更不负责“填补 NULL”——它只是计算时返回某个已存在值。如果你的主键列（比如 user_id）本身有缺失（NULL 或空字符串），直接在 SELECT 中用 FIRST_VALUE(user_id) 无法让这一行真正获得一个主键值；它只会把当前行所在窗口的第一行 user_id 拿过来，而如果第一行也是 NULL，结果还是 NULL。
常见错误现象：
– 查询结果中 FIRST_VALUE(user_id) OVER (PARTITION BY session_id ORDER BY event_time) 对所有行都返回 NULL
– 误以为加了 COALESCE 就能兜底，但没意识到窗口里压根没有非空值
- 主键维度缺失通常意味着数据接入或 ETL 过程出错，不是靠查询函数能“修复”的
-
FIRST_VALUE只能传播已有值，不能凭空生成或推断主键 - 若底层表主键列允许
NULL，说明建模阶段已放弃主键约束，此时用窗口函数回填属于掩耳盗铃
什么情况下可以用FIRST_VALUE做“伪回填”
仅当缺失发生在**同一业务实体的连续事件中**，且该实体在同一批数据里**至少有一条非空主键记录**，才可借助 FIRST_VALUE 向前后行广播这个值。典型场景：用户行为日志中，部分点击事件漏传 user_id，但同一次会话（session_id）里有登录事件带上了 user_id。
实操要点：
- 必须显式定义
PARTITION BY边界（如session_id、device_id），确保同一实体归一组 -
ORDER BY要按时间或事件序号升序，让含主键的那条记录排在前面 - 推荐搭配
IGNORE NULLS（PostgreSQL 14+、Oracle、BigQuery 支持；MySQL 8.0 不支持）：FIRST_VALUE(user_id) IGNORE NULLS OVER (PARTITION BY session_id ORDER BY event_time) - MySQL 用户需改用
COALESCE(user_id, LAG(user_id) OVER (...), LEAD(user_id) OVER (...))组合兜底
如何安全落地：从查询到更新的两步走
想真正把“回填结果”写回表，不能只靠 SELECT。必须拆成两步：先确认逻辑可行，再用 UPDATE ... JOIN 或子查询赋值。
以 PostgreSQL 为例，安全更新模式：
UPDATE events e
SET user_id = filled.val
FROM (
SELECT id,
FIRST_VALUE(user_id) IGNORE NULLS
OVER (PARTITION BY session_id ORDER BY event_time) AS val
FROM events
WHERE user_id IS NULL
) filled
WHERE e.id = filled.id AND filled.val IS NOT NULL;
关键约束条件：
- 子查询中
WHERE user_id IS NULL限制只处理缺失行，避免重复更新 - 外层
AND filled.val IS NOT NULL防止把空值写回去 - 务必在执行前对
session_id分组做抽样验证：SELECT session_id, COUNT(*), COUNT(user_id) FROM events GROUP BY session_id HAVING COUNT(user_id) = 0—— 若存在整组无主键，FIRST_VALUE仍无效
比FIRST_VALUE更稳的替代方案
当数据分布不规则（比如主键只出现在末尾事件、或跨天会话）、或数据库不支持 IGNORE NULLS 时，FIRST_VALUE 容易失效。此时应切换策略：
- 用
MAX(user_id) OVER (PARTITION BY session_id)：只要组内有一个非空值，就能全组广播，不依赖顺序 - 对 Hive/Spark SQL，改用
LAST_VALUE(user_id, TRUE) OVER (...)（TRUE表示忽略 NULL） - 终极兜底：在 ETL 脚本中用
ROW_NUMBER() + DENSE_RANK()构造临时主键，再关联原始维表补全，而非硬靠窗口函数“猜”
真正棘手的不是语法怎么写，而是得先说清：这个“缺失”，是采集端丢数据？还是清洗逻辑主动置空？前者修源，后者调逻辑——函数只是最后一道补救，不是创口贴。
