lead函数通过partition by user_id order by order_time取下一笔订单时间，核心是分组排序后获取下一行order_time，再结合时间差判断复购；必须处理null及数据库语法差异。
LEAD函数怎么取下一笔订单时间
LEAD函数的核心作用是“看后面一行”，对判断复购来说，就是让当前订单能直接拿到该用户下一次下单的order_time。必须按用户分组、按时间排序，否则取到的可能是别人的时间。
常见错误是只写LEAD(order_time)却忘了OVER子句里的PARTITION BY user_id ORDER BY order_time，结果全表乱序取值，复购判断全错。
- 必须显式指定
PARTITION BY user_id，否则不同用户的订单会混在一起比较 -
ORDER BY order_time要确保是升序（默认），降序会导致LEAD取到更早的订单 - 如果存在同一用户同秒多单，建议追加
order_id作为第二排序字段，避免窗口内顺序不确定
怎么定义“复购”并生成布尔标识
复购不是简单“有下一笔订单”，而是“下一笔订单发生在当前订单之后的合理时间内”。LEAD返回的只是时间戳，是否复购得靠业务规则判断，比如7天内再买算复购。
典型写法是用LEAD(order_time) OVER (...)结果和当前order_time做时间差计算，再套条件：
LEAD(order_time) OVER (PARTITION BY user_id ORDER BY order_time) AS next_order_time,
CASE
WHEN LEAD(order_time) OVER (PARTITION BY user_id ORDER BY order_time)
BETWEEN order_time AND order_time + INTERVAL '7 days'
THEN 1 ELSE 0
END AS is_rebuy
- PostgreSQL用
INTERVAL '7 days'，MySQL用DATE_ADD(order_time, INTERVAL 7 DAY)，SQL Server用DATEADD(day, 7, order_time) - 注意NULL处理：首单的
next_order_time一定是NULL，CASE里要覆盖，否则is_rebuy也会是NULL而非0 - 别直接用
next_order_time - order_time ，不同数据库日期减法返回类型不一致（天数/秒数/interval），易出错
为什么不能只靠LEAD判断首次复购用户
LEAD是逐行计算的，它只能告诉你“这一单是不是复购”，但无法直接回答“这个用户有没有发生过复购”。比如一个用户下了5单，只有第2、4单被标为is_rebuy = 1，你得再聚合才能知道ta是复购用户。
- 若目标是统计复购用户数，需在外层用
MAX(is_rebuy) = 1或COUNT(CASE WHEN is_rebuy = 1 THEN 1 END) > 0判断用户维度 - 若想查每个用户的首次复购时间，得在LEAD结果上再套
MIN(CASE WHEN is_rebuy = 1 THEN next_order_time END)，而不是直接用LEAD - LEAD本身不改变行数，原始多少行结果就多少行；真正做用户级分析时，漏掉这层聚合是常见疏忽
性能和NULL值怎么避坑
LEAD是窗口函数，数据量大时性能取决于分区键（user_id）的分布。如果少数超级用户占了80%订单，这些用户的分区会成为瓶颈。
- 确保
user_id和order_time上有联合索引（如(user_id, order_time)），加速窗口排序 - LEAD默认返回NULL（当无下一行时），但有些场景需要填默认值，比如
LEAD(order_time, 1, '9999-12-31') OVER (...)，避免后续计算报错 - 空值参与时间比较会整体返回NULL，例如
next_order_time > order_time在next_order_time为NULL时结果是NULL，不是FALSE——这点在WHERE过滤时尤其致命
实际跑的时候，先确认user_id和order_time数据质量，空值、异常时间（如'1970-01-01'）会直接污染LEAD结果。复购逻辑看似简单，卡点往往不在函数本身，而在时间字段的可信度。
