lag()仅提供上一行值，异常检测依赖差值计算、动态阈值、边界处理及严格按真实时间排序；首行返回null是正常设计，须用coalesce或case显式处理，禁在where中直接引用lag。
LAG() 本身不检测异常，它只提供上一行的值；真正起作用的是你如何用它算差值、设阈值、并处理边界和排序问题。
为什么 LAG(value) OVER (ORDER BY timestamp) 返回一堆 NULL？
首行没有“前一行”，LAG() 必然返回 NULL —— 这不是错误，是设计行为。若后续直接参与减法（如 value - LAG(value)），整列差值就全是 NULL。
- 用
COALESCE(LAG(value) OVER (ORDER BY timestamp), value)把首行差值设为 0（即自身减自身） - 更清晰的做法是显式判断：
CASE WHEN LAG(value) IS NULL THEN 0 ELSE value - LAG(value) END - 别在
WHERE里写LAG(value) IS NOT NULL—— 窗口函数不能出现在WHERE子句中，必须包一层子查询或 CTE
ORDER BY timestamp 为什么不能换成 id？
设备上报存在网络延迟、缓存重发、批量插入等情况，id 自增顺序 ≠ 物理采集顺序。用 ORDER BY id 会导致 LAG() 拿到错误的“前一个值”，突变判断完全失真。
- 时间字段必须是真实采集时间，如
event_time或sensor_ts - 若时间是字符串（如
'2026-09-01T14:22:05Z'），先转成TIMESTAMP类型再排序，否则字典序会错乱（例如'2026-09-01T9:59:59Z'排在'2026-09-01T10:00:00Z'后面） - 毫秒级重复很常见，务必加二级排序：
ORDER BY timestamp, sensor_id或ORDER BY timestamp, seq_no
怎么算相对跳变率并防除零？
绝对差值（如 ABS(value - LAG(value)) > 50）在量纲差异大的传感器中极易误报：电流从 1A→51A 是突变，温度从 20℃→70℃ 却可能是正常升温。
- 优先用相对变化率：
ABS((value - LAG(value)) / NULLIF(LAG(value), 0)) -
NULLIF(LAG(value), 0)比CASE WHEN LAG(value) = 0 THEN NULL ELSE ... END更简洁，且能拦截除零错误 - 阈值别写死，按设备类型分组动态设定：
PARTITION BY device_type后计算历史 95% 分位数作为阈值 - 采样频率影响判断逻辑：10ms 采样下连续 3 次跳变 >0.3，比单次跳变更可信
如何把突变点和上下文一起查出来？
只标出“哪一行突变了”不够，运维需要看到突变前值、后值、时间戳、设备 ID 才能快速定位。
- 在 SELECT 中直接展开：
LAG(value) OVER (ORDER BY timestamp) AS prev_value、LEAD(value) OVER (ORDER BY timestamp) AS next_value - 用布尔表达式标记风险：
ABS((value - LAG(value)) / NULLIF(LAG(value), 0)) > 0.35 AS is_spike，再在外层过滤 - 避免漏掉首尾：对首行，
prev_value是NULL或兜底值；对末行，next_value同理 —— 不要因缺失某侧值就丢弃整行 - 若需关联原始设备元数据（如厂商、型号），用
JOIN放在最外层，别塞进窗口计算里，否则影响性能和可读性
真正难的不是写出 LAG()，而是确认时间字段是否真实、重复值是否被唯一排序、NULL 是自然产生还是原始脏数据、以及阈值是否随设备类型和采样节奏动态调整——这些细节一错，结果就不可信。
