lag()必须配合order by才能定义“前一次”，否则数据库无法确定行序；需按业务时间字段排序并用partition by分组，null是首行正常信号而非错误，应结合索引与数据质量优化性能。
LAG() 必须配合 ORDER BY 才能定义“前一次”
不指定 ORDER BY 的 LAG() 没有意义——数据库根本不知道哪条记录算“前一条”。实际中常见错误是只按用户ID分组，却忽略时间维度排序，结果拉回来的可能是三天前的操作，甚至未来时间点（如果时间字段有脏数据）。
正确做法是：在 OVER 子句中明确用行为发生时间排序，且该时间字段必须可比较、非空、无歧义：
SELECT user_id, action, event_time, LAG(action) OVER (PARTITION BY user_id ORDER BY event_time) AS prev_action, LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time) AS prev_time FROM user_events;
-
PARTITION BY user_id确保只在同用户内回溯 -
ORDER BY event_time是关键，不能用id或其他逻辑序号替代，除非它严格对应时间先后 - 若存在毫秒级并发操作，建议用
ORDER BY event_time, id补充确定性排序
NULL 值不是 bug，是边界信号
每个用户的第一条记录，LAG() 必然返回 NULL。这不是函数失效，而是准确表达了“无前序行为”这一事实。很多同学一看到 NULL 就加 COALESCE(..., 'unknown') 掩盖问题，反而丢失了识别首次行为的能力。
真正该处理的是异常缺失：比如某用户中间突然断开10小时，再出现时 prev_time 距离当前超过阈值，这时应标记为“新会话”，而非强行填充。
- 用
LAG(event_time)计算时间差，判断是否属于同一会话（如间隔 ≤ 30 分钟） - 避免对
LAG(action)直接WHERE prev_action IS NOT NULL过滤——这会漏掉所有首条行为，影响路径起点统计 - 若需排除首条，应在外层用行号或条件标记后过滤，而非依赖
LAG()输出本身
性能陷阱：窗口函数在大数据量下容易拖慢查询
LAG() 本身不慢，但它的执行依赖完整排序和分区扫描。当 user_events 表超千万行且未优化时，PARTITION BY user_id ORDER BY event_time 可能触发磁盘临时表，查询从秒级升到分钟级。
提速关键在索引和剪枝：
- 必须有复合索引：
CREATE INDEX idx_user_time ON user_events(user_id, event_time) - 加时间范围限制（如
WHERE event_time >= '2024-06-01'），避免全表扫描 - 避免在子查询里嵌套多层窗口函数，LAG + LEAD + ROW_NUMBER 组合极易引发重复排序
- 如只需最近 N 条路径，考虑用
LIMIT配合物化中间结果，而非让窗口函数扫全量
跨设备/登录态场景下 user_id 不等于真实用户
如果业务存在游客登录、多端并行、token 失效重登等情况，单纯按数据库里的 user_id 分区会导致路径断裂或错连。例如：用户用微信扫码登录后又切到手机号登录，两个 ID 在表里被当作不同用户处理。
此时 LAG() 拉出来的“前一次行为”可能来自另一个身份，路径分析完全失真。
- 优先使用稳定标识符，如打通后的
unified_user_id或设备指纹device_id（需业务侧已做归因） - 若只能用原始
user_id，必须在查询前补上登录态合并逻辑（如关联login_sessions表做映射） - 警惕匿名行为：未登录用户的
user_id可能是 session_id 或随机字符串，生命周期短，LAG 结果仅具会话内参考价值
LAG() 返回的“前一次”就不可靠。这种情况下，得先确认数据采集粒度是否满足路径还原前提，而不是调参或换函数。
