LAG()+时间差判断断点最可靠，需严格PARTITION BY user_id ORDER BY event_time防跨用户错位，再用SUM(is_new_session) OVER()累加生成单调递增session_id，分步计算prev_time与time_gap更稳。
用 LAG() + 时间差判断会话断点
埋点日志天然按时间散列，但用户真实行为是分 Session 的。Presto 没有内置 session_id 字段时，必须靠 LAG() 推出上一行时间戳，再算间隔。关键不是“能不能算”，而是“怎么避免跨 user_id 错位”——必须严格 PARTITION BY user_id ORDER BY event_time，否则 A 用户的最后行为和 B 用户的第一行为被当成相邻行，LAG() 结果就全乱了。
常见错误是漏写 ORDER BY 或只写 ORDER BY event_time 不加 PARTITION BY，导致全局排序后计算时间差，结果完全不可信。另外注意 Presto 的 DATEDIFF('second', ...) 只支持部分单位，用 event_time - LAG(event_time) INTERVAL 'SECOND' 更稳妥。
SUM() OVER() 累加生成连续 Session ID
SUM(is_new_session) OVER(PARTITION BY user_id ORDER BY event_time) 是生成单调递增 Session ID 的核心。它不是计数器，而是“条件累加器”：每遇到一个 is_new_session = 1 就 +1，等于 0 就保持原值。这个特性让同一会话内所有行共享同一个 ID，且 ID 严格按时间顺序递增。
容易踩的坑：
• 用 ROW_NUMBER() 替代 —— 它对每行都 +1，无法合并连续行为；
• 忘记 ORDER BY 导致窗口无序，SUM 结果随机；
• 在外层再套一层 GROUP BY session_id 却没把 event_time 包进聚合，引发 Presto “non-deterministic grouping” 报错 Cannot nest window functions。
避免在窗口函数里嵌套复杂表达式
比如把 COALESCE(LAG(event_time), event_time - INTERVAL '31' MINUTE) 直接塞进时间差计算，会让执行计划变重，尤其在百亿级日志中，Presto 可能因内存不足 fallback 到磁盘 spill，查询耗时翻倍。
更稳的做法是分两步：
• 第一步 CTE 或子查询先算出 prev_event_time 和 time_gap_seconds；
• 第二步再基于该列做布尔判断和累加；
• 这样每个字段职责单一，Presto 优化器更容易复用中间结果，也方便加 WHERE time_gap_seconds > 1800 提前过滤。
注意 Presto 0.247+ 的优化器缺陷对窗口查询的影响
0.246 及之后版本存在一个已知问题：当窗口函数后紧跟 ORDER BY 或 LIMIT（比如想取每个 session 的首条行为），优化器可能误判 ORDER BY 冗余而直接裁掉，导致结果顺序错乱或条数不对。
临时规避方式：
• 显式加 SELECT * FROM (...) t ORDER BY user_id, session_id, event_time，不依赖窗口内隐式排序；
• 避免在含窗口函数的查询顶层直接写 LIMIT，改用 CTE 包一层再限流；
• 如果业务强依赖顺序，升级前务必用真实埋点数据跑回归，重点验证带 LIMIT 的会话首行提取逻辑。
