LEAD(event_time) OVER (ORDER BY event_time)可获取下一行时间值，必须指定ORDER BY确保逻辑顺序，配合PARTITION BY device_id防止跨组混算，并用二级排序ORDER BY event_time, id解决重复时间乱序问题。
LEAD() 怎么拿到下一行的时间值？
核心就是用 LEAD() 把当前行的 event_time 和下一行的 event_time 拉到同一行对比。它默认取下 1 行，所以最简写法是：LEAD(event_time) OVER (ORDER BY event_time)。注意必须加 ORDER BY，否则窗口无序，结果不可靠；也别漏掉括号里的字段名——写成 LEAD() 不带参数会报错。
怎么算出断层时长并过滤出异常间隔？
把当前时间与 LEAD() 结果相减，就能得到相邻事件的间隔。不同数据库语法略有差异：
- PostgreSQL / Redshift：直接
LEAD(event_time) OVER (...) - event_time，结果是interval类型 - MySQL 8.0+：用
TIMESTAMPDIFF(SECOND, event_time, LEAD(event_time) OVER (...))转成秒数更易过滤 - SQL Server：推荐
DATEDIFF(second, event_time, LEAD(event_time) OVER (...))
查断层通常要找「超出预期」的间隔，比如期望每 5 分钟一条，那就加 WHERE gap_seconds > 300。别忘了 LEAD() 最后一行返回 NULL，会导致 gap_seconds 为 NULL，需用 WHERE gap_seconds IS NOT NULL 排除。
为什么 ORDER BY 必须严格匹配业务逻辑顺序？
如果数据按设备分组采集，但只按 event_time 全局排序，LEAD() 就可能把设备 A 的末尾和设备 B 的开头连起来，误判为断层。此时必须加 PARTITION BY device_id，再 ORDER BY event_time。另一个常见坑是时间字段含毫秒但排序精度不足，导致“相同时间”多行乱序——建议显式加上唯一字段如 id 做二级排序：ORDER BY event_time, id。
LEAD() 查断层时性能要注意什么？
大表上跑 LEAD() 本质是全表扫描 + 窗口排序，没索引会很慢。确保 ORDER BY 字段（如 event_time）有索引；如果还用了 PARTITION BY，复合索引更优，例如 (device_id, event_time)。另外，别在子查询里套多层窗口函数来“先过滤再 LEAD”，这往往比直接 WHERE + LEAD() 更慢——先用时间范围把数据量压下来再开窗口才是正解。
断层识别的关键不在函数本身，而在于你定义“正常间隔”的业务规则是否覆盖了时区、夏令时、批量补录等现实扰动。LEAD() 只负责算差值，解释权永远在人手里。
