识别跳跃值需先用LAG(value) OVER(ORDER BY ts)计算相邻差值，注意显式排序、处理NULL及避免负数阈值混乱；再用PERCENTILE_CONT或动态基线（如IQR）设定自适应阈值，并优先采用时间范围窗口应对非均匀序列。
用 LAG() 和 LEAD() 计算相邻差值
识别跳跃值的第一步，是拿到当前行与前一行（或后一行）的数值差。窗口函数 LAG() 最直接：它能安全地跨行取值，不依赖自连接或子查询，也不受分组边界干扰。
常见错误是直接用 LAG(value) 但没指定 ORDER BY —— 窗口函数在无显式排序时行为未定义，结果可能每次执行都不一样。
实操建议：
- 必须在
OVER子句中明确写ORDER BY timestamp或ORDER BY id，确保序列顺序唯一且稳定 - 差值计算建议用
value - LAG(value) OVER (ORDER BY ts)，而非LAG(value) - value，避免负数阈值判断混乱 - 对首行（
LAG()返回NULL），差值会是NULL，后续过滤时需加WHERE diff IS NOT NULL
设定动态跳跃阈值：用 PERCENTILE_CONT() 替代固定数值
用固定阈值（如“差值 > 100 就报警”）容易误报：数据本身波动大时，100 可能很常见；数据平缓时，20 都算异常。更稳的方式是基于当前窗口内历史差值的分布定界。
PostgreSQL / SQL Server / Oracle 支持 PERCENTILE_CONT(0.95)，可算出过去 N 行差值的 95% 分位数作为上限。
实操建议：
- 先用 CTE 或子查询算出每行的
diff，再套一层窗口计算分位数，例如：PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY diff) OVER (ROWS BETWEEN 99 PRECEDING AND CURRENT ROW) - 注意
ROWS BETWEEN ...的范围要覆盖足够多历史点（比如 100 行），否则分位数抖动剧烈 - MySQL 8.0+ 不支持
PERCENTILE_CONT，得改用APPROX_PERCENTILE（BigQuery）或临时表 + 变量模拟
处理时间非均匀序列：用 INTERVAL 约束窗口范围
传感器数据或日志常有采样不均问题——某次更新隔了 5 分钟，下次隔了 2 小时。若只按行数滑动窗口（如 ROWS BETWEEN 19 PRECEDING AND CURRENT ROW），实际时间跨度可能从 10 分钟跳到 3 天，导致阈值失效。
实操建议：
- 优先使用时间范围窗口：
ORDER BY ts RANGE BETWEEN INTERVAL '1 HOUR' PRECEDING AND CURRENT ROW - PostgreSQL 支持
INTERVAL直接写，MySQL 需转为秒数：RANGE BETWEEN 3600 PRECEDING AND CURRENT ROW - 注意：
RANGE要求排序字段是数值或日期类型，不能是字符串时间戳（如'2023-01-01 12:00'必须先转为TIMESTAMP）
避免误标连续跳跃中的“正常”中间值
真实异常常以“台阶式”出现：值从 10 → 105 → 108 → 107。若只比前一行，105 是异常，但 108 和 107 差值很小，会被放过——而它们其实是异常状态的延续，不是回归正常。
解决思路不是看单步变化，而是看是否脱离了“近期合理区间”。可用 MIN()/MAX() 窗口聚合构建动态基线：
- 计算最近 20 行的
AVG(value)和STDDEV(value)，把超出AVG ± 3×STDDEV的点标为异常 - 或者更鲁棒：用
PERCENTILE_CONT(0.25)和PERCENTILE_CONT(0.75)算 IQR，异常区间设为[Q1 - 1.5×IQR, Q3 + 1.5×IQR] - 关键点：这类基线必须用
ROWS BETWEEN 19 PRECEDING AND CURRENT ROW，不能用RANGE，否则时间空档会导致窗口内行数不足，基线失真
连续跳跃最难的不是检测，而是定义“何时算恢复”。这个边界往往得结合业务——比如温度传感器连续 5 分钟高于阈值才触发告警，而不是单点超标就报。
