FIRST_VALUE函数必须配合OVER子句使用，且需同时指定PARTITION BY user_id和ORDER BY created_at，缺一不可；推荐用子查询+窗口函数实现每行广播首单金额，并确保联合索引(idx_orders_user_created)以提升性能。
FIRST_VALUE函数必须配合窗口定义使用，否则报错
直接写 FIRST_VALUE(amount) 会触发 ERROR: window function call requires an OVER clause。PostgreSQL 不允许裸用窗口函数，必须显式声明 OVER 子句来定义分区和排序逻辑。
首单消费金额的核心是「按用户分组、按时间升序排、取第一条的 amount」，所以 OVER 必须包含 PARTITION BY user_id ORDER BY created_at —— 缺一不可。
- 漏掉
PARTITION BY：所有记录被当成一个大组，返回的是全局最早一笔订单的金额，不是每个用户的首单 - 漏掉
ORDER BY：窗口默认无序，FIRST_VALUE行为未定义（实际常返回当前行值，极易误导） -
ORDER BY用降序（DESC）：会拿到最新一笔，不是首单
获取每个用户的首单金额，推荐用子查询+窗口函数
想在结果中展示每个用户自己的首单金额（比如用于计算复购率、首单客单价分布），不能只靠 FIRST_VALUE 做 SELECT，还得确保每行对应其所属用户的首单值。常见写法是子查询或 CTE：
SELECT user_id, amount, created_at, FIRST_VALUE(amount) OVER (PARTITION BY user_id ORDER BY created_at) AS first_order_amount FROM orders;
这个写法会在每条订单记录后追加一列 first_order_amount，值等于该 user_id 的最早订单金额。注意它不改变原始行数，只是“广播”首单值到该用户所有订单上。
- 如果只要每个用户一行（去重后的首单记录），得用
DISTINCT ON (user_id) ORDER BY user_id, created_at或ROW_NUMBER()过滤 -
FIRST_VALUE返回的是表达式值，不是整行；若要首单的完整记录（如商品ID、渠道等），需改用ROW_NUMBER() = 1配合子查询 - 字段名别用
first_value——和函数名冲突，某些客户端或旧版本 pg 可能报语法警告
NULL 值和重复时间戳会影响排序稳定性
当多个订单的 created_at 完全相同时，FIRST_VALUE 可能随机选一个（取决于底层 tuple 顺序），导致同一用户多次查询结果不一致。
- 解决办法：在
ORDER BY中加入唯一列兜底，例如ORDER BY created_at, id（假设id是主键自增） - 如果
created_at允许为NULL，默认排在最前（NULLS FIRST），可能把空时间戳误判为首单；显式写ORDER BY created_at NULLS LAST更安全 -
amount本身为NULL时，FIRST_VALUE照常返回NULL，不会跳过——若业务要求忽略 NULL 金额的订单，得先过滤或用COALESCE处理
性能关键：确保 (user_id, created_at) 有联合索引
窗口函数本身不走索引，但 PARTITION BY user_id ORDER BY created_at 的执行效率高度依赖底层数据物理顺序。没有合适索引时，PostgreSQL 得先排序整个表，I/O 和内存开销陡增。
- 建索引语句：
CREATE INDEX idx_orders_user_created ON orders (user_id, created_at); - 避免只建
(created_at, user_id)：顺序反了，对PARTITION BY user_id无效 - 大表上线前务必
EXPLAIN ANALYZE验证，关注是否出现Sort节点及占用内存大小
真正容易被忽略的是时间精度——如果 created_at 是 TIMESTAMP WITHOUT TIME ZONE 且应用写入时没控制精度（比如毫秒级写入但业务只关心天），可能因微小差异导致本该同天的首单被拆散。必要时可在窗口排序里用 DATE(created_at)，但要注意这会让索引失效，得权衡。
