窗口函数通过LAG()获取用户相邻行为时间戳，结合TIMESTAMPDIFF（MySQL）或EXTRACT(EPOCH FROM)（PostgreSQL）计算秒级间隔，再按阈值（如300秒）判断是否新建session，最后用累计和生成session_id并聚合MAX-MIN时长。
窗口函数怎么配合时间差计算活跃时长
直接用 LAG() 或 LEAD() 拿到同一用户相邻行为的时间戳，再用 EXTRACT(EPOCH FROM ...)（PostgreSQL）或 TIMESTAMPDIFF()（MySQL）算秒级/分钟级间隔。关键不是“统计总时长”，而是识别“连续活跃段”——比如用户在 10:00、10:02、10:05 有操作，中间没超 5 分钟就算一次活跃 session。
常见错误是直接对所有记录求 MAX(time) - MIN(time)，这会把用户全天零散行为全算进一个时长里，完全失真。
- 必须按
user_id分组排序，否则LAG()拿到的不是前一次操作 - 排序字段得是真实时间字段（如
event_time），不能用自增 ID 或无序时间戳 - PostgreSQL 中
LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time)是基础写法；MySQL 8.0+ 才支持窗口函数，低版本得用变量模拟
如何定义“一次活跃”并切分 session
窗口函数本身不切 session，它只提供相邻行数据。真正切分靠的是“时间间隔判断 + 累计标记”。典型做法：先用 LAG() 算出与上一次操作的间隔，再用条件判断是否超过阈值（比如 300 秒），最后用累计和 SUM() 生成 session_id。
示例（PostgreSQL）：
SELECT
user_id,
event_time,
CASE WHEN EXTRACT(EPOCH FROM (event_time - LAG(event_time) OVER (
PARTITION BY user_id ORDER BY event_time
))) > 300 THEN 1 ELSE 0 END AS is_new_session,
SUM(CASE WHEN EXTRACT(EPOCH FROM (event_time - LAG(event_time) OVER (
PARTITION BY user_id ORDER BY event_time
))) > 300 THEN 1 ELSE 0 END) OVER (
PARTITION BY user_id ORDER BY event_time
) AS session_id
FROM user_events;这个 session_id 就是每个活跃段的唯一标识，后续可按它聚合时长。
聚合 session 时长时要注意 NULL 和边界
LAG() 对每组第一条记录返回 NULL，直接参与减法会导致整行结果为 NULL。必须显式处理：
- 用
COALESCE(LAG(...), event_time)填充，但这样第一条记录间隔为 0，不合理 - 更稳妥的是在外部再套一层过滤或用
ROW_NUMBER()排除首行：只对ROW_NUMBER() > 1的行计算间隔 - session 最终时长 = 该 session 内
MAX(event_time) - MIN(event_time)，不是所有间隔之和（后者会漏掉最后一条记录后的静默期）
别忘了加 GROUP BY user_id, session_id，否则 MIN/MAX 会跨 session 错乱。
不同数据库对时间类型和窗口的支持差异
MySQL 8.0 支持 LAG()，但 TIMESTAMPDIFF(SECOND, ..., ...) 才能替代 PostgreSQL 的 EXTRACT(EPOCH FROM ...)；SQL Server 要用 DATEADD() 配合 DATEDIFF()；而 Hive/Spark SQL 中 unix_timestamp() 是常用转换方式。
性能上，如果表没建 (user_id, event_time) 复合索引，PARTITION BY user_id ORDER BY event_time 会触发大量排序，千万级数据可能卡住。线上环境务必确认执行计划里有 Index Scan。
真正难的不是写对窗口函数，而是定义清楚“活跃”的业务含义——是登录就算？还是有点击/提交才算？这个逻辑一旦定错，后面所有时长统计都偏移，而且很难从结果反推问题在哪。
