lag() 返回 null 是边界问题而非数据缺失，因首行无前驱行；需用 coalesce 填充并区分自然 null 与原始 null；计算变化率应使用 (value - lag(value)) / nullif(lag(value), 0)，按设备类型分组设动态阈值；order by 必须用转换后的 timestamp 而非 id。
LAG() 返回 NULL 时为什么不是数据缺失而是边界问题？
在传感器时间序列中，LAG() 对第一行返回 NULL 是正常行为，不是数据损坏。它只依赖前一行，首行无“前一行”，所以必然为 NULL。若误把 NULL 当异常过滤掉，会丢失关键起点判断依据。
实操建议：
- 用
COALESCE(LAG(value) OVER (ORDER BY timestamp), value)填充首行，避免后续计算中断（比如做差值时除零或NULL传播） - 明确区分两种
NULL：一种是LAG()自然产生（可预期），另一种是原始数据本身为NULL（需单独清洗） - 时间戳必须严格有序且无重复；若存在毫秒级重复，需加
ROW_NUMBER()辅助排序，否则LAG()行为不可控
怎么用 LAG() 计算相邻点变化率并设阈值？
直接用 value - LAG(value) 得到绝对跳变值，但传感器量纲差异大（温度 vs 电流），更稳妥的是算相对变化率：(value - LAG(value)) / NULLIF(LAG(value), 0)。注意分母为 0 必须拦截，NULLIF 比 CASE WHEN 更简洁。
常见错误现象：
- 未处理
LAG(value)=0导致除零错误 —— 错误信息通常是division by zero - 阈值写死（如 >0.3），但不同传感器动态范围不同，应按设备类型分组后计算历史 95% 分位数作为阈值
- 忽略采样频率：10ms 采样下 0.5s 内连续 50 次跳变可能是真实事件，不能单看单次差值
为什么 ORDER BY 必须用 timestamp 而不是 id？
传感器写入数据库的 id 可能是自增主键，但不等于采集顺序。网络延迟、设备缓存、批量上报都会导致 id 和真实时间错位。用 ORDER BY timestamp 才反映物理世界的先后关系。
使用场景提醒：
- 若
timestamp是字符串（如'2024-03-15T10:23:45Z'），必须先转成TIMESTAMP类型再排序，否则字典序可能出错（例如'2024-03-15T10:23:45Z''2024-03-15T9:59:59Z'） - 跨时区数据要统一转为 UTC 时间戳，避免夏令时切换造成时间倒流假象
- 部分传感器带毫秒但数据库字段精度不足（如 MySQL
DATETIME只到秒），需提前截断或升级字段类型
LAG() 无法检测“缓慢漂移”类异常怎么办？
LAG() 只看上一点，对持续数分钟缓慢上升/下降的漂移不敏感。这类异常需要对比更长时间窗口，比如用 AVG(value) OVER (ORDER BY timestamp ROWS BETWEEN 59 PRECEDING AND CURRENT ROW) 算滚动均值，再与当前值比较。
性能与取舍：
- 窗口越大，计算越重；60 行滚动均值比
LAG()多约 30 倍 CPU 开销，高吞吐场景需压测 - 不要嵌套窗口函数（如在
LAG()结果上再套AVG()），会导致执行计划退化，应拆成 CTE 或子查询 - 真正难的是“多尺度异常”：既要单点跳变，又要趋势偏移，还得识别周期性干扰——这时候
LAG()只是起点，不是终点
实际部署时，最易被忽略的是时间精度对齐和 NULL 的语义区分。传感器原始数据里的 NULL 和窗口函数生成的 NULL 必须走不同分支处理，混在一起会漏报或误报。
