row_number() 必须配合 partition by user_id 和 order by order_date asc 才能正确标识每个用户的首次下单；漏掉 partition by 会导致全表连续编号，order by 方向错误或字段不当会误判“首次”，且需用子查询或 cte 过滤 rn = 1。
ROW_NUMBER() 必须配合 PARTITION BY 才能按用户分组编号
单独写 ROW_NUMBER() OVER(ORDER BY order_date) 会把全表所有订单从 1 开始连续编号，根本分不清谁是谁的首次下单。关键在 PARTITION BY user_id —— 它强制 SQL 把数据先按用户切开，再在每个切片里独立编号。
常见错误是漏掉 PARTITION BY，结果查出来全是 rn = 1 的假象（其实是全表第一条），或者编号乱序无法对应到具体用户。
-
PARTITION BY user_id是硬性前提，没有它就不是“每个用户”而是“整个表” - 字段名要和你表中真实列名一致，比如可能是
customer_id、member_id，别直接抄user_id - 如果用户 ID 有 NULL 值，那这些行会被归到同一组（NULL 视为相同值），可能干扰结果
ORDER BY 必须用带时序语义的字段，且方向决定“首次”含义
“首次下单”本质是时间上最早的一条，所以 ORDER BY order_date ASC 才对。如果写成 DESC，编号为 1 的反而是最新订单。
容易踩的坑：
- 用了非时间字段排序，比如
ORDER BY order_amount，那rn = 1就是金额最小的单，不是最早的单 - 字段含 NULL：
NULL默认排在最前（ASC）或最后（DESC），可能让 NULL 时间的订单被误判为“首次” - 没处理时区或字符串时间：如果
order_date是VARCHAR类型的 '2025-01-01'，排序正常；但如果是 '01/01/2025'，就会按字典序错乱
窗口函数不能直接进 WHERE，必须套子查询或 CTE
ROW_NUMBER() 是窗口函数，生成的是计算列，不能在同一个查询层级用 WHERE rn = 1 过滤——SQL 执行顺序决定了 WHERE 先于 OVER 执行。
正确写法只有两种：
- 用子查询：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date ASC) AS rn FROM orders ) t WHERE t.rn = 1
- 用 CTE（更易读、可复用）：
WITH first_orders AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date ASC) AS rn FROM orders ) SELECT user_id, order_date FROM first_orders WHERE rn = 1
别试图省事写成 SELECT *, ROW_NUMBER() ... WHERE ROW_NUMBER() = 1，语法直接报错。
统计首次下单日期时，别只取日期字段而丢掉用户上下文
单纯 SELECT MIN(order_date) FROM orders GROUP BY user_id 能拿到每个用户的最早日期，但拿不到该日期对应的完整订单记录（比如订单号、金额、地址等）。而 ROW_NUMBER() 方案返回的是整行，天然保留原始字段。
如果你只需要日期本身（比如做宽表特征），用聚合更快；但只要涉及“首次下单的完整信息”，就必须用窗口函数+筛选。另外注意性能：在 (user_id, order_date) 上建联合索引能显著加速 PARTITION BY + ORDER BY 过程。
