LAG()可计算相邻行差值以识别数值突变，需配合ORDER BY确保顺序、处理NULL、设定阈值，并用ROW_NUMBER()实现连续跳变分组；浮点精度与排序稳定性是关键陷阱。
用 LAG() 和差值判断连续数值是否突变
窗口函数本身不直接标出“异常跳变”，但能帮你算出相邻行的差值，这是识别跳变的基础。关键不是函数多高级，而是差值计算后怎么定义“异常”。比如某字段 value 在时间有序下突然从 100 变成 350，差值 250 就可能超标。
实操建议：
- 先用
ORDER BY明确业务顺序（如ORDER BY timestamp或ORDER BY id），否则LAG()返回结果不可控 - 用
LAG(value) OVER (ORDER BY timestamp)拿前一行值，再和当前行做减法 - 差值绝对值超过阈值（如
ABS(value - LAG(value) OVER (...)) > 200）就标记为疑似跳变 - 注意 NULL 处理：首行
LAG()返回 NULL，减法结果也是 NULL，需用COALESCE或WHERE ... IS NOT NULL过滤
用 ROW_NUMBER() + 差值分组识别连续跳变段
单点跳变好找，但如果你要识别“连续 3 行都发生 >100 的正向跳变”这类模式，就得把跳变行为聚成组。这时候不能只靠 LAG()，得结合行号做差分分组（即“gaps-and-islands”思路）。
实操建议：
- 先生成布尔标记列：
is_jump = CASE WHEN value - LAG(value) OVER (ORDER BY ts) > 100 THEN 1 ELSE 0 END - 再用
ROW_NUMBER() OVER (ORDER BY ts)和ROW_NUMBER() OVER (PARTITION BY is_jump ORDER BY ts)做差，相同差值即属同一跳变连续段 - 最后按差值分组，
COUNT(*)看连续跳变长度，MIN(ts)/MAX(ts)看区间 - 别直接在
WHERE里过滤is_jump = 1后再分组——会破坏原始序列连续性，导致行号错位
警惕浮点精度与排序稳定性引发的误判
看似简单的差值判断，在真实数据中容易翻车。最常见两个坑：一是 value 是 DOUBLE 或 DECIMAL(18,6)，相减后因精度丢失让本该为 0 的差值变成 -0.0000000001；二是 ORDER BY 字段存在重复值（如多条记录同秒级时间戳），导致 LAG() 返回哪一行不确定。
实操建议：
- 对浮点型字段，差值比较改用
ABS(a - b) 而非 <code>= 0，或提前用ROUND(value, 4)统一精度 - 排序字段必须带唯一性兜底，例如
ORDER BY timestamp, id，避免仅靠timestamp排序时窗口行为不可复现 - 测试时手动查几条
LAG()结果：运行SELECT id, value, LAG(value) OVER (ORDER BY ts, id) AS prev_val FROM t LIMIT 10，眼见为实
性能敏感场景下避免多重嵌套窗口
如果表有千万级数据，又写成三层子查询（外层筛跳变、中层算分组、内层取 LAG），执行计划很可能走不了索引，全表扫描+多次排序。窗口函数不是银弹，开销比普通聚合高得多。
实操建议：
- 把
LAG()、ROW_NUMBER()等放同一层 SELECT 中，不要拆到不同子查询——多数引擎能合并优化 - 确保
ORDER BY字段上有索引，例如CREATE INDEX idx_ts_id ON table_name (timestamp, id) - 跳变阈值尽量静态（如写死
> 200），避免用子查询动态算阈值，否则窗口无法下推 - 若只需告警不需全量分析，先用
WHERE timestamp > NOW() - INTERVAL '1 hour'限定范围再开窗
实际中最容易被忽略的是排序字段的唯一性保障和浮点差值的容忍处理——这两点不提前验证，跑出来的“异常列表”可能一半是假阳性。
