会话切分是按用户行为间空闲超时（如30分钟）将连续行为聚合成会话，不能仅用LAG()简单判断，因其无法传递会话重置状态；需用SUM(CASE WHEN 超时 THEN 1 ELSE 0 END)累积生成会话ID，并显式处理LAG的NULL、分区排序及性能优化。
什么是会话切分，为什么不能只用 LAG() 简单判断
会话切分本质是把用户连续的行为（比如点击、页面访问）按“空闲超时”聚合成一段，中间间隔超过阈值（如 30 分钟）就切分为新会话。很多人第一反应是用 LAG() 比较当前行和上一行时间差，打个标记再累计求和——但这样会漏掉跨组传递问题：一旦某次间隔超限，后续所有行的会话 ID 都得继承新编号，而窗口函数无法在当前行直接引用“前一个会话是否已重置”的状态。
真正可靠的做法是构造一个能传播变化的累积标识，核心在于用条件累加代替布尔标记。
用 SUM() + CASE 实现会话 ID 累积生成
关键不是标记“这一行是否超时”，而是标记“这一行是否该开启新会话”。只要把“超时”转化为 1，否则为 0，再用 SUM() 窗口函数累积，就能自然形成递增的会话 ID。
-
ORDER BY user_id, event_time必须显式指定，否则窗口顺序不确定，会话 ID 会错乱 - 时间差计算要用
EXTRACT(EPOCH FROM ...)转成秒，避免interval类型无法直接比较 - 对每个
user_id独立分区，否则不同用户行为会互相干扰
SELECT
user_id,
event_time,
SUM(
CASE
WHEN EXTRACT(EPOCH FROM (event_time - LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time))) > 1800
THEN 1
ELSE 0
END
) OVER (PARTITION BY user_id ORDER BY event_time) AS session_id
FROM user_events;注意 LAG() 的 NULL 行处理和边界行为
首条记录的 LAG(event_time) 是 NULL，会导致整个 CASE 表达式结果为 NULL，进而让 SUM() 累积中断（PostgreSQL 中 SUM(NULL) 仍为 NULL）。必须显式补默认值。
- 用
COALESCE(LAG(...) OVER (...), event_time)把首行的前一行时间设为自身，使差值为 0，不触发新会话 - 或者更稳妥：用
ROW_NUMBER() = 1单独判断首行，强制设is_new_session = 0 - 如果业务要求每个用户第一条行为就作为新会话起点，那就把首行的
CASE结果固定为 1
性能与数据量大的实际约束
这个写法在千万级用户行为表上跑得慢，主要卡在排序和窗口扫描。别指望靠加索引跳过排序——ORDER BY user_id, event_time 的复合排序无法被单字段索引完全覆盖。
- 真实场景建议先用
WHERE event_time >= CURRENT_DATE - INTERVAL '7 days'限定时间范围 - 如果要高频查询，预计算列（如
session_id）+ 物化视图比纯 SQL 更可行 -
EXTRACT(EPOCH FROM ...)在大表上比event_time - LAG(...) > INTERVAL '30 minutes'略快，因为后者涉及 interval 运算和隐式类型转换
最易被忽略的一点：会话 ID 是相对序号，不是全局唯一标识；如果需要导出或关联其他系统，得拼上 user_id 和起始时间才能准确定义一个会话。
