LEAD()不预测，只取下一行值；必须配合PARTITION BY device_id ORDER BY timestamp确保设备内时序正确，否则跨设备错配导致突增误报。
LEAD() 怎么拿到“下一个时间点的值”
LEAD() 的核心作用是取当前行之后第 N 行的某列值，常用于和后续时间点对比。它必须配合 ORDER BY 使用，否则结果无序、不可靠；不加 PARTITION BY 时默认全表视为一个分区——这对跨设备比较很危险，容易把设备 A 的末尾值和设备 B 的开头值错配。
典型写法：LEAD(value, 1) OVER (PARTITION BY device_id ORDER BY timestamp)。这里 1 是偏移量（默认就是 1），device_id 隔离设备，timestamp 保证时序正确。漏掉 PARTITION BY device_id 是最常见错误，会导致突增误报率飙升。
怎么定义“异常突增”并过滤出问题行
LEAD() 本身不判断异常，只提供对比基础。真正检测突增得靠计算当前值与下个值的差值或比值，再设阈值。比如：当前温度 25℃，下个值是 78℃，增幅 212%，远超合理范围。
常用判断逻辑（放在 WHERE 或子查询中）：
-
LEAD(value) OVER (...) - value > 10—— 绝对增量超 10 单位 -
(LEAD(value) OVER (...) * 1.0 / NULLIF(value, 0)) > 3.0—— 相对增幅超 200%，用NULLIF防除零 - 结合滑动窗口更稳：先用
AVG() OVER (ROWS BETWEEN 5 PRECEDING AND CURRENT ROW)算短期均值，再和 LEAD 值比
LEAD() 返回 NULL 怎么处理才不丢数据
每组最后一行的 LEAD() 必然为 NULL（后面没数据了），如果直接在 WHERE 中写 LEAD(value) > value * 2，这一行会被过滤掉——但你其实关心的是“突增发生前的那一刻”，也就是倒数第二行，它有有效 LEAD 值。所以判断逻辑必须作用于“有 LEAD 值的行”，而不是试图给最后一行硬补值。
安全做法：
- WHERE 条件里显式排除
LEAD(value) IS NULL，确保只分析有后续观测的点 - 不要用
COALESCE(LEAD(value), value)来填充，这会让末尾突增完全不可见 - 若需标记“潜在末尾异常”，应单独查
ROW_NUMBER() OVER (...) = COUNT(*) OVER ()定位末尾行，另做逻辑
PostgreSQL 和 MySQL 8.0+ 的细微差别要注意
语法基本一致，但 MySQL 8.0+ 对 ORDER BY 子句要求更严：如果 timestamp 有重复值，MySQL 可能随机排序，导致 LEAD 结果不稳定；PostgreSQL 则允许用 ORDER BY timestamp, id 加二级排序保确定性。
性能上，LEAD() 是窗口函数，依赖排序，大数据量时务必在 (device_id, timestamp) 上建联合索引。没索引时，OVER (PARTITION BY device_id ORDER BY timestamp) 可能触发全表排序，单次查询从毫秒级拖到秒级。
另外，SQL Server 和 Oracle 支持 LEAD(value, 1, default_value) 的第三个参数设默认值，但 PostgreSQL 和 MySQL 不支持——别写，会报错 function lead(numeric, integer, numeric) does not exist。
