LAG函数需显式指定默认值、严格搭配ORDER BY和PARTITION BY，并统一时区处理异常数据，否则首行NULL、排序混乱或时区偏差会导致时间差计算错误。
LAG 函数怎么写才不会漏掉第一条记录
LAG 返回前一行的值，但第一行没有“前一行”，默认返回 NULL。如果直接用 LAG 算时间差，首条记录的差值会是 NULL，容易被 WHERE 过滤掉或参与计算时报错。
- 显式指定默认值：
LAG(created_at, 1, '1970-01-01') OVER (ORDER BY created_at)，避免 NULL 干扰后续减法 - 务必搭配
ORDER BY—— 没有明确排序，LAG的“上一行”完全不可预测 - 若按设备/用户分组分析，必须加
PARTITION BY device_id，否则跨设备混排会导致时间差失真
时间差单位选秒、分钟还是间隔类型
不同数据库对时间相减结果类型不一致：PostgreSQL 返回 interval，MySQL 和 SQL Server 默认转成秒数或天数，直接减可能报错或精度丢失。
- PostgreSQL 推荐用
EXTRACT(EPOCH FROM (created_at - LAG(created_at)))转成秒，便于阈值判断（如 > 3600 秒算断连） - MySQL 用
TIMESTAMPDIFF(SECOND, LAG(created_at), created_at)，避免日期相减出负数或溢出 - 别直接写
created_at - LAG(created_at)—— 在某些引擎里结果不可比、不可索引，也难调试
WHERE 条件里能不能直接用 LAG 计算的字段
不能。窗口函数不能出现在 WHERE 或 GROUP BY 中，因为执行顺序是 WHERE → GROUP BY → SELECT → 窗口函数。
- 必须用子查询或 CTE 包一层，例如：
SELECT * FROM (SELECT *, LAG(created_at) OVER (ORDER BY created_at) AS prev_time FROM events) t WHERE EXTRACT(EPOCH FROM (created_at - prev_time)) > 300
- CTE 更易读，但注意有些旧版 MySQL 不支持；若用子查询，别忘了给别名，否则报
Every derived table must have its own alias - WHERE 中误写
LAG(...) > 300会直接报语法错误，不是逻辑错，是解析不过
间隙检测时如何排除脏数据干扰
真实日志常有重复时间戳、未来时间、时区混乱，直接算差会把噪声当间隙。
- 先过滤异常值：
WHERE created_at BETWEEN '2024-01-01' AND NOW() AND created_at = created_at（排除 NULL 和非法时间） - 对同一秒内多条记录，用
ROW_NUMBER() OVER (PARTITION BY created_at ORDER BY id)去重，只保留第一条 - 如果数据带时区（如
timestamptz），确保所有比较在统一时区做，比如created_at AT TIME ZONE 'UTC'，否则夏令时切换点附近会出现虚假大间隙
实际跑起来最常卡在排序不明确和 NULL 处理上——看似简单的一行 LAG，背后得盯住三件事：顺序、空值、时区。
