first_value必须配合order by使用，否则报错或结果不可预测；需显式指定排序字段（如purchase_time）并补充次级排序（如order_id）保障确定性，且必须用partition by分组，ignore nulls可跳过空值。
FIRST_VALUE必须配合窗口函数ORDER BY使用
不写 ORDER BY 会报错或返回不可预测结果，因为 FIRST_VALUE 依赖明确的排序逻辑来定义“首次”。它不会自动按时间戳排序，哪怕字段名叫 created_at 或 purchase_time。
常见错误是只写 PARTITION BY user_id 却漏掉 ORDER BY purchase_time，这时数据库可能按物理存储顺序取值，导致同一用户在不同查询中返回不同渠道。
- 必须显式指定时间列排序，例如
ORDER BY purchase_time ASC - 若存在并列时间（同一秒多笔订单），需补充次级排序，如
ORDER BY purchase_time ASC, order_id ASC保证确定性 - 慎用
NULLS FIRST/LAST—— 若时间字段有空值，不声明会导致部分用户被排除在窗口外
渠道字段为空时FIRST_VALUE会返回NULL
如果某条购买记录的 channel 是 NULL，而它恰好排在窗口最前面，FIRST_VALUE(channel) 就返回 NULL，哪怕该用户后续有非空渠道。这不是bug，是函数严格按排序后第一行取值的结果。
真实业务中常遇到埋点缺失、老数据清洗不全等情况，直接取 FIRST_VALUE(channel) 可能放大脏数据影响。
- 用
FIRST_VALUE(channel) IGNORE NULLS（PostgreSQL 14+、Oracle、SQL Server 支持）跳过空值 - 旧版本可用
COALESCE(FIRST_VALUE(channel) OVER (...), FIRST_VALUE(COALESCE(channel, 'unknown')) OVER (...))绕过，但性能差 - 更稳妥的做法是预处理：在子查询中先过滤或补缺渠道，再套窗口函数
想查每个用户的首次渠道，别忘了PARTITION BY user_id
漏写 PARTITION BY 会让 FIRST_VALUE 对整张表计算，所有用户都得到同一个“全局首次”渠道，完全偏离需求。
典型误写：FIRST_VALUE(channel) OVER (ORDER BY purchase_time) —— 这是在全表范围内找最早一笔订单的渠道，不是每个用户的首次。
- 正确写法必须包含
PARTITION BY user_id ORDER BY purchase_time - 注意
user_id类型一致性：字符串ID带空格、大小写混用，或数字ID隐式转字符串，都可能导致分区断裂 - 若需去重（如同一用户同一天多笔，只算一次渠道），得先用
DISTINCT ON（PostgreSQL）或ROW_NUMBER() = 1预聚合，再对结果跑FIRST_VALUE
MySQL 8.0+和旧版兼容性差异明显
MySQL 5.7 不支持窗口函数，强行写 FIRST_VALUE 会直接报错 ERROR 1305 (42000): FUNCTION xxx.FIRST_VALUE does not exist。即使升级到 8.0，语法细节仍有坑。
比如 MySQL 要求 IGNORE NULLS 必须紧跟在函数参数后，不能像 PostgreSQL 那样放在 OVER 子句里；而且不支持 RESPECT NULLS 显式声明（默认就是 respect）。
- MySQL 8.0+ 写法：
FIRST_VALUE(channel) IGNORE NULLS OVER (PARTITION BY user_id ORDER BY purchase_time) - MySQL 5.7 或更早：只能用自连接或变量模拟，例如
(SELECT channel FROM orders o2 WHERE o2.user_id = o1.user_id ORDER BY purchase_time LIMIT 1)，但大数据量下性能极差 - 确认版本用
SELECT VERSION()，别依赖客户端显示的“MySQL”字样——有些云服务后台是 MariaDB 兼容层，行为可能不同
真正难的不是写出语法正确的 FIRST_VALUE，而是搞清“首次”的业务定义：是按创建时间？支付成功时间？还是订单状态变为“已完成”的时间？这些字段来源不同、更新延迟不同，选错一个，整个分析口径就偏了。
