会话是同一用户连续操作且间隔不超过阈值（如30分钟）的逻辑单元；不能直接用group by时间字段，因其会错误切分跨时段连续行为或合并同时间段内超时行为，必须用lag()判断时间断点并sum()累计生成session_id。
什么是会话（session）以及为什么不能直接用 GROUP BY 时间字段
用户会话不是自然存在的数据库记录，而是业务定义的逻辑单元：同一用户连续操作、间隔不超过某阈值（比如 30 分钟），就算一次会话。直接 GROUP BY DATE_TRUNC('hour', event_time) 或按天分组，会把跨小时但实际连续的行为硬切开，也把同小时内间隔超时的两次行为合并——这两种都错。
用 LAG() + 时间差判断会话断点
核心思路是：对每个用户按时间排序，算当前事件和上一事件的时间差；若差值超过阈值（如 1800 秒），就标记为新会话起点。这需要窗口函数配合布尔累积计算。
- 先用
LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time)拿到上一行时间 - 用
EXTRACT(EPOCH FROM (event_time - prev_time))算秒级间隔（PostgreSQL）；MySQL 用TIMESTAMPDIFF(SECOND, prev_time, event_time) - 生成会话 ID：用
SUM(is_new_session) OVER (PARTITION BY user_id ORDER BY event_time)累加标记
示例片段（PostgreSQL）：
SELECT
user_id,
event_time,
SUM(is_new_session) OVER (PARTITION BY user_id ORDER BY event_time) AS session_id
FROM (
SELECT
user_id,
event_time,
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 AS is_new_session
FROM events
) t;
MySQL 8.0+ 和旧版 MySQL 的写法差异
MySQL 8.0 支持窗口函数，写法接近 PostgreSQL；但 5.7 及更早版本不支持 LAG() 和 SUM() OVER，必须用变量模拟，且顺序依赖 ORDER BY 在子查询中强制生效。
- MySQL 5.7 必须写成：先
ORDER BY user_id, event_time的派生表，再在外部用@prev_time和@session_id逐行赋值 - 变量赋值顺序容易出错：必须在同一
SELECT中完成比较、更新、输出，不能拆到不同字段 - MySQL 8.0 推荐优先用窗口函数，变量方案在并发或优化器重排时可能不稳定
会话拆分后怎么统计停留时长和事件数
拿到 session_id 后，聚合就简单了，但要注意边界：
-
MIN(event_time)和MAX(event_time)就是会话起止时间，差值即停留时长（单位取决于数据库，PostgreSQL 返回 interval，MySQL 返回秒） - 不要用
COUNT(*)当“活跃时长”，那是事件数；真实停留时长是时间跨度 - 如果某会话只有 1 条事件，
MAX - MIN为 0，是否算作有效会话需按业务定（比如过滤掉HAVING COUNT(*) > 1）
常见漏点：没按 user_id 和 session_id 双重分组，导致不同用户的会话 ID 冲突；或者在子查询里漏了 PARTITION BY user_id，让跨用户的时间被错误连贯计算。
