LAG函数必须配合ORDER BY使用，否则结果不可靠；需结合PARTITION BY按用户分组、用COALESCE处理首行NULL，并统一用秒级整数计算时间差以确保跨库兼容性。
LAG 函数必须配合 ORDER BY 使用，否则结果不可靠
SQL 中 LAG 是窗口函数，它不关心物理行序，只依赖 OVER 子句中明确指定的排序逻辑。如果漏写 ORDER BY，数据库可能按任意顺序取上一行——尤其在 MySQL 8.0+ 或 PostgreSQL 中，看似“正常”的结果只是巧合，换数据或换版本就出错。
实操建议：
- 始终在
OVER中写全ORDER BY event_time（或你定义的业务时间字段），不要依赖主键或插入顺序 - 若存在时间相同事件，需补充二级排序，例如
ORDER BY event_time, id，避免非确定性 - PostgreSQL 允许
NULLS FIRST/LAST，MySQL 不支持；如时间字段含NULL，提前用COALESCE(event_time, '1970-01-01')处理
计算时间差要先转成可运算类型，别直接减 datetime
不同数据库对 datetime 相减的支持差异很大：MySQL 允许 event_time - LAG(event_time) 但返回秒数（仅当字段是 TIMESTAMP）；PostgreSQL 会报错；SQL Server 要用 DATEDIFF。硬写跨库表达式大概率失败。
实操建议：
- MySQL：用
TIMESTAMPDIFF(SECOND, LAG(event_time) OVER (...), event_time)显式指定单位 - PostgreSQL：用
EXTRACT(EPOCH FROM (event_time - LAG(event_time) OVER (...)))::INTEGER - SQL Server：用
DATEDIFF(second, LAG(event_time) OVER (...), event_time) - 统一推荐：优先用秒级整数，便于后续聚合或分桶；避免直接返回 interval 类型（如 PostgreSQL 的
INTERVAL），它难参与 WHERE 或 GROUP BY
第一行的 LAG 结果为 NULL，需用 COALESCE 或 CASE 处理
LAG 对分区首行返回 NULL，如果直接参与减法或除法，整个字段变成 NULL（例如 event_time - NULL → NULL）。线上报表里突然出现大片空白间隔，八成是这个原因。
实操建议：
- 用
COALESCE(LAG(event_time) OVER (...), event_time)把首行“间隔”设为 0 秒（或设为'1970-01-01'再算差） - 更清晰的做法是显式标记：
CASE WHEN LAG(event_time) OVER (...) IS NULL THEN 0 ELSE ... END - 如果业务要求首行无间隔（比如用户首次登录不计时），就保留
NULL，但查询时加WHERE interval_sec IS NOT NULL过滤
按用户/设备分组计算间隔，必须用 PARTITION BY 隔离上下文
常见错误是只写 ORDER BY event_time，没加 PARTITION BY user_id。结果是把张三最后一次操作和李四第一次操作强行连起来算间隔，数据完全失真。
实操建议：
- 只要涉及“每个用户的操作序列”，
OVER (PARTITION BY user_id ORDER BY event_time)是铁律 - 复合分组如
PARTITION BY user_id, device_type要提前确认业务语义是否需要隔离设备维度 - 注意
PARTITION BY字段值不能为NULL，否则这些行会被归到同一组；可用COALESCE(user_id, -1)预处理
实际执行时最易被忽略的是时间字段的精度和时区。比如日志里存的是 UTC 时间但业务按本地时区理解间隔，或者 DATETIME(3) 和 TIMESTAMP 混用导致毫秒截断——这些不会报错，但算出来的秒数偏差几秒，排查起来极耗时间。
