LEAD函数通过PARTITION BY user_id和ORDER BY event_time将下一行event_time拉至当前行，空值结合30分钟超时阈值精准识别跳出点；需联合索引优化性能，并用中间表固化is_bounce字段避免重复计算。
LEAD函数怎么定义“下一个行为”
跳出点本质是用户会话中最后一个行为，而LEAD的作用就是把下一行的event_time或page_url拉上来——只要下一行为空，当前行大概率就是跳出点。关键不是“找最后一条”，而是“找下一条不存在的那条”。
必须按用户+时间排序，否则LEAD拉出来的“下一个”毫无业务意义：
SELECT user_id, event_time, page_url, LEAD(event_time) OVER (PARTITION BY user_id ORDER BY event_time) AS next_event_time FROM user_behavior_log
注意：PARTITION BY user_id不能漏，否则跨用户错位；ORDER BY event_time必须严格升序，跳转时间乱序会导致next_event_time为NULL但实际并非跳出。
如何准确标记跳出行为（非简单判NULL）
仅靠LEAD(event_time) IS NULL会误标：比如日志延迟入库、ETL截断、用户真正在页面停留超24小时等场景，都会让next_event_time为空，但不等于跳出。
更稳妥的方式是结合会话超时窗口判断：
- 先用
LAG或窗口函数算出当前行为与上一行为的时间差（event_time - LAG(event_time) OVER (...)） - 再定义“会话结束阈值”，例如30分钟无新行为即视为会话终止
- 当前行满足：
next_event_time IS NULL OR next_event_time - event_time > INTERVAL '30 minutes'
这样既覆盖真实跳出，也兼容会话自然终结，避免把ETL失败日志当成用户行为终点。
性能陷阱：大表上LEAD容易慢的根本原因
LEAD本身不慢，慢在PARTITION BY + ORDER BY触发全局重分布和排序——尤其当user_id倾斜（如爬虫账号占百万级行为）、或event_time无索引时，执行计划常出现WindowAgg节点堆积大量数据。
优化方向很实际：
- 确保
(user_id, event_time)有联合索引（PostgreSQL/MySQL 8.0+ 支持索引加速窗口函数） - 预过滤：先用子查询限制时间范围（如
WHERE event_time >= '2024-05-01'），别在全量日志上跑LEAD - 替代思路：对超高频用户，可先用
GROUP BY user_id取MAX(event_time)拿到疑似跳出时间点，再反查原始日志做精细标记
跳出点识别后怎么落地到宽表或告警
直接在报表SQL里嵌套多层LEAD易读性差且难复用。推荐拆成两步：
第一步生成带标记的中间表（加字段is_bounce）：
CREATE TABLE user_session_enhanced AS
SELECT *,
CASE
WHEN LEAD(event_time) OVER (PARTITION BY user_id ORDER BY event_time) IS NULL
THEN 1
WHEN LEAD(event_time) OVER (PARTITION BY user_id ORDER BY event_time) - event_time > INTERVAL '30 minutes'
THEN 1
ELSE 0
END AS is_bounce
FROM user_behavior_log;第二步聚合时只扫这个表，SUM(is_bounce)就是跳出次数，比每次重算LEAD快得多。
注意：is_bounce是会话粒度标记，不是页面粒度——同一个用户单次会话里只应有一个跳出点（最后那个行为），重复标记说明窗口逻辑没控好。
真正麻烦的是跨设备ID合并、登录态丢失导致的user_id分裂——这时候跳出统计会系统性偏高，得先做用户归因，再谈LEAD。
