LEAD是漏斗行为追踪最直接的窗口函数，必须配合PARTITION BY user_id和ORDER BY event_time确保同一用户时间序列正确，否则跨用户拼接导致路径混乱；重复时间戳需加event_id等二级排序。
LEAD 是做漏斗行为追踪最直接的窗口函数，但它不是“自动连路径”的魔法工具——必须配合明确的用户粒度、严格的时间排序和合理的事件定义，否则结果全是错的。
LEAD 必须搭配 PARTITION BY user_id + ORDER BY event_time
漏斗分析本质是看“同一个用户”在时间轴上的行为序列，LEAD 只负责取下一行，但下一行是不是“该用户的下一个行为”，全靠 PARTITION BY 和 ORDER BY 控制。
常见错误：只写 ORDER BY event_time，没加 PARTITION BY user_id —— 这会导致 A 用户的点击被拼到 B 用户的注册后面，漏斗路径彻底混乱。
- 正确写法：
LEAD(event_type, 1) OVER (PARTITION BY user_id ORDER BY event_time) - 如果表里有重复时间戳（比如毫秒精度丢失），建议补上二级排序：
ORDER BY event_time, event_id - MySQL 8.0+ / SQL Server 2016+ / PostgreSQL 11+ 都支持；旧版 MySQL（
用 LEAD 计算行为间隔（如注册→下单耗时）
漏斗不只是看“有没有下一步”，更要看“多久之后发生”。直接用 LEAD 拿到下一行时间，再做减法即可，但要注意 NULL 和类型转换。
-
LEAD(event_time) OVER (PARTITION BY user_id ORDER BY event_time)返回的是下一行的原始时间值，类型与原字段一致 - SQL Server 中用
DATEDIFF(second, event_time, LEAD(...))；MySQL 用TIMESTAMPDIFF(second, event_time, LEAD(...)) - 首行或末行必然返回 NULL，计算前建议加
WHERE lead_event_time IS NOT NULL过滤无效行 - 避免跨天计算出负数：确保
event_time是DATETIME或TIMESTAMP，不是字符串
LEAD(offset=2) 不等于“跳过中间步骤”，而是严格取第2行
有人想用 LEAD(event_type, 2) 直接拿到“注册→支付”路径，这是误解。它取的是当前行往后数第 2 行的事件，不管中间那行是不是“下单”——如果用户行为有缺失或乱序，结果就不可信。
- 真正可靠的“注册后是否支付”，应分两步：先用
LEAD标出“下一步事件”，再用条件过滤（如WHERE event_type = 'register' AND lead_event_type = 'pay'） - 若要支持“跳过中间环节”的柔性漏斗（比如注册后任意行为都算进入下一阶段），得用
MIN(lead_event_time) FILTER (WHERE lead_event_type IN ('pay', 'add_cart'))类逻辑（PostgreSQL）或改用子查询 -
offset必须是正整数，不能是变量表达式（如LEAD(x, @n)在 SQL Server 中会报错）
LEAD + IGNORE NULLS 仅限 SQL Server 2022+ / Azure SQL
真实日志常含 NULL 事件或埋点失败数据。默认 LEAD 遇到 NULL 就停住，导致“注册→NULL→支付”时拿不到支付时间。新版支持 IGNORE NULLS，但兼容性极差。
- 可用写法：
LEAD(event_type) IGNORE NULLS OVER (PARTITION BY user_id ORDER BY event_time) - 老版本替代方案：先用
ROW_NUMBER() OVER (...)给非 NULL 行编号，再自连接或用LAG/LEAD套子查询 - 别在 WHERE 条件里提前
IS NOT NULL过滤——这会破坏用户行为序列完整性，漏掉关键中断点
LEAD 之前，先统一清洗事件口径，比调函数参数重要十倍。 
