FIRST_VALUE()默认不满足向下填充需求，因其未指定窗口帧时采用ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，会取整个分区内首个非空值（含后续行），而非截至当前行的最近非空值。
FIRST_VALUE() 本身不能直接实现向下填充，必须配合 ORDER BY 和窗口帧（ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW）来模拟“最近非空值”的行为。
为什么 FIRST_VALUE() 默认不满足向下填充需求？
默认情况下 FIRST_VALUE() 在未指定窗口帧时，会使用整个分区的默认帧（ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING），这会导致它总是取该分组里的第一个非空值（甚至可能是后面行的值），而不是“截至当前行为止的最近非空值”。
常见错误现象：
– 填充结果全为同一值（如首行值）
– 空值后出现错误回填（用到了后续行的值）
关键点：
– 必须显式限定帧范围为 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
– ORDER BY 列需反映业务顺序（如时间戳、ID递增）
– NULL 值在排序中默认排在最前或最后（取决于数据库），可能干扰逻辑
正确写法：带帧定义 + COALESCE 处理 NULL
核心思路是：对每个非空值，让它“覆盖”后续所有直到下一个非空值之间的空行。但 FIRST_VALUE() 本身不跳过 NULL，所以得先构造一个能“携带”上一个有效值的表达式。
实操建议：
– 用 CASE WHEN value IS NOT NULL THEN value END 构造辅助列
– 对该列用 FIRST_VALUE(...) 并限定帧
– 最后用 COALESCE(value, filled_value) 合并
SELECT
id,
event_time,
metric,
COALESCE(
metric,
FIRST_VALUE(CASE WHEN metric IS NOT NULL THEN metric END)
OVER (PARTITION BY group_id ORDER BY event_time
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
) AS metric_ffill
FROM events;
注意：
– PARTITION BY 决定分组边界（如用户 ID、设备 ID）
– event_time 必须可排序且无重复；若有重复，需加次级排序（如 id）保证确定性
– 某些数据库（如 Presto/Trino）不支持在 FIRST_VALUE 的表达式里直接写 CASE，需改用子查询或 LAST_VALUE 配合 IGNORE NULLS
更可靠替代方案：使用 IGNORE NULLS（如果数据库支持）
PostgreSQL 14+、Oracle、BigQuery、SQL Server 2022+ 支持 FIRST_VALUE(... IGNORE NULLS)，语义更贴近直觉，且无需手动构造 CASE：
FIRST_VALUE(metric) IGNORE NULLS
OVER (PARTITION BY group_id ORDER BY event_time
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
但要注意：
– MySQL 目前（8.0）仍不支持 IGNORE NULLS
– 即使支持，也必须搭配显式帧定义，否则默认帧仍可能导致跨行污染
– IGNORE NULLS 是语法糖，底层仍依赖窗口帧行为
容易被忽略的陷阱
向下填充不是纯函数行为，它强依赖数据顺序和完整性：
– 缺失值出现在首行时，无法填充（无上游非空值）
– 若 ORDER BY 列有 NULL，会导致该行被排到最前/最后，破坏填充链路
– 分区键（PARTITION BY）漏写或写错，会让填充跨业务实体“串值”
– 使用 RANGE 帧而非 ROWS 帧，在存在重复排序键时可能意外合并多行，导致填充异常
实际调试时，建议先用 ROW_NUMBER() OVER (...) 和原始值并列输出，肉眼验证填充路径是否符合预期。
