FIRST_VALUE返回NULL是因为它取排序后第一行的原始值，不跳过NULL；需显式控制ORDER BY中NULL位置或前置过滤。

为什么FIRST_VALUE返回NULL而不是第一个非NULL值

FIRST_VALUE不会跳过NULL，它只按ORDER BY指定的顺序取窗口内排序后的第一行原始值。如果该行的字段本身就是NULL，结果就是NULL——哪怕后面几十行全是有效值。常见诱因包括：ORDER BY created_at但部分记录created_at IS NULL，或直接对可能为空的email列开窗却没处理排序优先级。

ORDER BY里没控制NULL位置是最大陷阱

不同数据库对NULL在排序中的默认位置不一致：PostgreSQL默认NULLS FIRST，MySQL和SQL Server通常NULLS LAST（但不可依赖）。不显式声明会导致行为漂移。必须用以下任一方式锁定逻辑：

• ORDER BY email IS NULL, email：把非NULL排前面，再按值排序
• ORDER BY CASE WHEN email IS NOT NULL THEN 0 ELSE 1 END, email：语义更清晰，兼容性更好
• 避免ORDER BY email这种写法——既无法控制NULL位置，字符串排序还可能错乱（如'9'排在'10'前）

IGNORE NULLS参数不是万能解药

IGNORE NULLS确实能让FIRST_VALUE(email) IGNORE NULLS OVER (...)跳过NULL取首个非NULL值，但它有硬性限制：

• 仅PostgreSQL 14+、Oracle、SQL Server 2022+支持；MySQL 8.0+和旧版PostgreSQL不认这个语法
• 即使支持，也只作用于目标列本身，不解决排序键含NULL导致的分区混乱问题
• 若整个分组所有值都是NULL，仍返回NULL（无值可跳）

真正稳妥的做法：提前过滤或构造有效排序键

靠窗口函数内部兜底风险高，生产环境建议前置处理：

• 在WHERE子句中先排除无效数据：WHERE order_time IS NOT NULL，干净利落
• 用CASE预处理排序字段：ORDER BY CASE WHEN phone IS NOT NULL THEN 0 ELSE 1 END, created_at
• 若需保留空值行但只取有效首值，用COALESCE(FIRST_VALUE(CASE WHEN email IS NOT NULL THEN email END), 'N/A')，但注意嵌套后仍受窗口帧影响

最易被忽略的是：即便加了PARTITION BY，只要ORDER BY没稳住NULL位置，不同数据库、甚至同一数据库不同版本都可能返回不同结果——这不是bug，是标准允许的未定义行为。