会话划分需将用户连续活跃操作（如30分钟内）聚合成session_id，核心是用LAG()获取前一行时间并判断间隔是否超阈值，再通过SUM()累计求和生成递增会话ID，需注意分区、时间类型、索引及NULL处理。
什么是会话（Session）划分的典型需求
实际业务中，用户行为日志常按时间序列记录，但原始数据没有天然的“会话”边界。比如网页浏览、App点击流，需要把连续活跃（如30分钟内）的操作聚合成一个session_id，用于计算人均会话时长、跳出率等指标。窗口函数本身不直接生成会话，但它能高效支撑会话划分的中间步骤——尤其是排序、差值计算和分组标识。
LAG() + 时间差判断是划分会话的核心逻辑
会话的本质是「上一次操作距当前操作超过阈值」，即出现断点。关键不是用ROW_NUMBER()或RANK()，而是用LAG()拿到前一行时间，再比对间隔：
- 假设表为
events，含字段user_id、event_time - 先按用户+时间排序，再用
LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time) - 计算时间差：
event_time - LAG(event_time) OVER (...)（注意单位：PostgreSQL用INTERVAL，MySQL用UNIX_TIMESTAMP()） - 若差值 > 1800秒（30分钟），标记为新会话起点
SELECT *,
CASE
WHEN event_time - LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time) > INTERVAL '30 minutes'
THEN 1
ELSE 0
END AS is_new_session
FROM events;
如何用SUM()窗口函数生成连续session_id
is_new_session只是0/1标记，真正要的是递增的会话ID。这时用累计求和：SUM(is_new_session) OVER (PARTITION BY user_id ORDER BY event_time)，它会把每个“1”之后的所有行都计入同一组。
- 注意必须用
ORDER BY event_time，否则SUM()无序导致ID错乱 - 不要用
GROUP BY提前聚合，会丢失单条事件粒度 - MySQL 8.0+、PostgreSQL、BigQuery、Spark SQL均支持；Hive需确认版本（>=3.0）
常见错误：
- 忘记PARTITION BY user_id，导致跨用户累加
- 时间字段类型不一致（如字符串 vs timestamp），LAG()返回NULL，差值计算失败
- 阈值单位混淆：PostgreSQL写INTERVAL '30 minutes'，MySQL得用SEC_TO_TIME(1800)或直接秒数比较
性能与边界情况处理
会话划分在大数据量下容易慢，尤其当event_time无索引或存在大量空值时：
- 确保
(user_id, event_time)有联合索引（B-tree），加速OVER排序 - 若
event_time含NULL，LAG()返回NULL，会导致差值为NULL →CASE默认走ELSE分支，首行永远不算新会话。应显式处理：LAG(event_time) IGNORE NULLS（PostgreSQL/BigQuery支持，MySQL不支持，需先FILTER或子查询清洗） - 多设备登录同一账号？
user_id是否已做去重映射？会话划分结果依赖上游用户识别质量
会话划分看着简单，但时间精度、NULL处理、索引缺失这三点，最容易在线上跑出错数据或超时。别只盯着窗口函数语法，先确认时间字段干净、可排序、有索引。
