session打桩的核心判断逻辑是先明确以用户id和时间间隔（如30分钟无新事件）定义session边界，再用lag()获取上一行时间并判断是否超阈值来标记新session起始点，最后通过sum()累积生成连续session id。
Session打桩的核心判断逻辑是什么
关键不是“怎么写窗口函数”，而是先明确 Session 的边界定义：通常以用户ID + 时间间隔（比如30分钟内无新事件）为断点。窗口函数本身不自动识别Session，它只是帮你按序分组、计算差值或累积状态——真正的Session切分依赖 LAG() 或 ROW_NUMBER() 配合时间差判断。
常见错误是直接用 GROUP BY user_id 粗粒度聚合，结果把跨时段的多次访问合并成一个假Session；或者用 OVER (PARTITION BY user_id ORDER BY event_time) 却没做时间断点检测，导致窗口内包含多个真实Session。
用LAG()识别Session起始点
最稳的打法是：对每个 user_id 按 event_time 排序，用 LAG(event_time) 取上一行时间，再判断是否超过阈值（如1800秒）：
SELECT *,
CASE
WHEN event_time - LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time) > INTERVAL '1800' SECOND
THEN 1
ELSE 0
END AS is_new_session
FROM logs;
-
INTERVAL '1800' SECOND在 PostgreSQL 中生效；MySQL 用TIMESTAMPDIFF(SECOND, LAG(...), event_time) > 1800；BigQuery 用TIMESTAMP_DIFF(event_time, LAG(event_time) OVER (...), SECOND) > 1800 - 注意时区：确保所有
event_time已转为统一时区（如UTC），否则跨时区用户会误判断点 - 首行的
LAG()返回 NULL，需用COALESCE(..., event_time)或直接让CASE落入 ELSE 分支，避免漏掉第一个事件
用SUM()累积生成Session ID
is_new_session 是标记位，要变成连续的Session ID，得用累计求和：
SELECT *,
SUM(is_new_session) OVER (PARTITION BY user_id ORDER BY event_time) AS session_id
FROM (
SELECT *,
CASE
WHEN event_time - LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time) > INTERVAL '1800' SECOND
THEN 1
ELSE 0
END AS is_new_session
FROM logs
) t;
这个 SUM() 窗口必须严格匹配 PARTITION BY user_id ORDER BY event_time，否则Session ID会在用户间串号或顺序错乱。别试图用 ROW_NUMBER() 替代——它只计数不累积，无法继承前序Session状态。
性能提示：大表上务必在 (user_id, event_time) 建复合索引，否则 LAG() 和 SUM() OVER 会全表排序，延迟飙升。
打桩字段该加在哪一级
Session打桩本质是给原始日志行打标签，不是聚合后结果。所以最终字段（如 session_id、session_start、session_length）必须挂载在明细行上，而非 GROUP BY session_id 后的汇总层。
如果后续要算每个Session的首次/末次事件，可用 MIN(event_time) OVER (PARTITION BY session_id) 和 MAX(event_time) OVER (PARTITION BY session_id)，但注意：这些窗口必须基于已生成的 session_id 字段重分区，不能嵌套在未打桩的原始窗口里——否则逻辑循环，执行报错或结果错乱。
最容易被忽略的是空值处理：当某用户只有一条日志，LAG() 为空，is_new_session 为 0，但这条记录仍应属于一个独立Session——靠 SUM() 的累积特性自然覆盖（首行 sum=0，但你可 +1 或用 ROW_NUMBER() OVER (...) WHERE ... 补正，取决于业务是否要求Session ID从1开始）。
