lead(status, 1, 'no_next') over (partition by user_id order by event_time, event_id) 可可靠获取“下一个状态”，必须指定partition by和order by，否则结果不可靠。
LEAD 函数怎么写才能拿到“下一个状态”
直接用 LEAD(status) 很容易，但错在没指定排序依据——窗口函数不保证物理顺序，必须显式用 ORDER BY event_time（或能唯一确定事件时序的字段）。否则同一用户多次登录/登出可能被乱序拉取，导致“登出后紧接着登出”这种荒谬流转。
常见错误写法：LEAD(status) OVER (PARTITION BY user_id) —— 缺少 ORDER BY，结果不可靠。
正确写法要点：
-
LEAD(status, 1, 'unknown')：第二个参数是偏移量（默认 1），第三个是缺失时的填充值，避免NULL干扰后续条件判断 -
PARTITION BY user_id必须加上，否则跨用户混排，A 用户登出可能被当成 B 用户的“上一状态” - 排序字段建议用
event_time；若存在毫秒级并发事件，需补充event_id做二级排序，防止并行写入导致的排序歧义
如何识别合法的状态流转（比如 login → logout）
不能只查 LEAD(status) 值，得结合当前行和下一行构成元组判断。典型做法是把当前状态和下一状态拼成字符串或用条件表达式做匹配。
例如追踪登录后是否正常登出：
SELECT *
FROM (
SELECT
user_id,
status AS curr_status,
LEAD(status) OVER (PARTITION BY user_id ORDER BY event_time, event_id) AS next_status,
LEAD(event_time) OVER (PARTITION BY user_id ORDER BY event_time, event_id) AS next_time
FROM events
) t
WHERE curr_status = 'login' AND next_status = 'logout';
注意点：
- 过滤条件必须放在外层
WHERE，不能在窗口内用FILTER（多数数据库不支持该语法） - 如果想排除“login → login”这类异常重入，可加
next_time - event_time > INTERVAL '1 second'防止毫秒级重复事件干扰 - 某些场景需要排除中间插入了其他状态（如 login → error → logout），此时得用
LEAD(status, 2)或改用LAG+LEAD组合判断三元组
为什么 LEAD 拿不到最后一条记录的 next_status
这是窗口函数定义决定的：LEAD 是向后看，最后一行之后没有数据，自然返回 NULL（或你指定的默认值）。这不是 bug，是预期行为。
但实际分析中，常需标记“未闭环”路径，比如 login 后无 logout 就算会话泄漏。这时别忽略默认值的作用：
- 用
LEAD(status, 1, 'no_next')替代默认NULL，后续可用next_status = 'no_next'显式捕获末尾 - 若业务中
'no_next'可能是真实状态，就换用不会冲突的哨兵值，比如'__EOS__' - 不要用
IS NULL判断末尾——有些数据库对空字符串、空格、NULL的等值比较行为不一致，统一用显式默认值更稳
性能和边界问题：大数据量下怎么避免 OOM 或超时
LEAD 本身不引发全表扫描，但 PARTITION BY + ORDER BY 要求数据库为每个分区构建有序内存结构。用户量大、单用户事件多时（如 IoT 设备每秒上报），容易撑爆 work_mem（PostgreSQL）或 sort_buffer_size（MySQL）。
实操缓解策略：
- 先按时间范围过滤再开窗：
WHERE event_time >= '2024-06-01'，别在全量表上直接LEAD - 对
user_id建复合索引：(user_id, event_time, event_id)，让排序走索引，避免磁盘临时文件 - 若只需统计流转频次而非明细，用
COUNT(*) FILTER (WHERE curr_status='login' AND next_status='logout')替代子查询，减少中间结果集 - Spark SQL 或 Flink SQL 中，注意
LEAD在动态窗口（如 session window）里不适用，得切到ROW_NUMBER()+ 自连接，逻辑更重但可控
真正麻烦的是事件时间乱序——比如客户端本地时钟回拨，导致 event_time 不具备单调性。这时候光靠 LEAD 会得出反逻辑流转，必须前置清洗或引入服务端打点时间戳。
