LAG(value) - value 返回NULL是因为首行无前驱值，LAG默认返回NULL，参与运算即得NULL；须用CASE或COALESCE处理首行，并严格按业务排序、分组、防除零，否则突变判断不可信。

能直接定位突变行，但必须处理好排序、NULL 和业务定义——漏掉任意一项，结果就不可信。

为什么 LAG(value) - value 会返回一堆 NULL

第一行没有“前一行”，LAG(value) 默认返回 NULL；一旦参与减法（如 value - LAG(value)），整条结果就是 NULL。这不是报错，是预期行为。

• 用 COALESCE(LAG(value), value) 把首行差值设为 0（即自身减自身）
• 或更清晰地写：CASE WHEN LAG(value) IS NULL THEN 0 ELSE value - LAG(value) END
• 别试图在 WHERE 里过滤 LAG() IS NOT NULL——窗口函数不能出现在 WHERE 子句中

突变判断不能只看差值绝对值，得结合业务场景

单纯 ABS(value - LAG(value)) > 100 很危险：金额从 100 到 200 是+100，但从 10000 到 10100 也是+100，后者未必算“突变”。

• 用相对变化率更稳妥：ABS((value - LAG(value)) / NULLIF(LAG(value), 0)) > 0.3（加 NULLIF 防除零）
• 时间序列中，突变常需排除首行和节假日断点，建议先用 ROW_NUMBER() OVER (ORDER BY ts) 标记序号，再限定 rn > 1
• 若数据按用户/设备分组波动，必须加 PARTITION BY user_id，否则 A 用户末尾和 B 用户开头会被错误拉通计算

ORDER BY 不写或写错，突变结果全是假的

LAG() 完全不认表的插入顺序或主键顺序，只认 OVER (ORDER BY ...) 里写的字段。排序字段一旦有重复（比如多条记录同秒写入），数据库可能任意打乱它们的相对位置。

• 必须用带业务意义的字段排序，如 created_at、event_time，而非 id（除非你确认 id 严格递增且无删改）
• 存在时间精度问题时（如 MySQL 的 DATETIME 只到秒级），务必补二级排序：ORDER BY created_at, id
• MySQL 5.7 及更早版本不支持窗口函数，强行执行会报 ERROR 1064；此时只能用变量模拟或应用层处理，但变量方式在并发或大结果集下极易出错

怎么把突变行连同上下文一起查出来

只标出“哪一行突变了”不够，常需查看突变前后的原始值、时间、关联 ID 等上下文信息。

• 直接在 SELECT 中展开：LAG(value) OVER (ORDER BY ts) AS prev_value、LEAD(value) OVER (ORDER BY ts) AS next_value
• 避免多次调用 LAG() 计算同一列，性能无额外开销，但可读性更强
• 如果要高亮突变点，可用布尔表达式：(value - LAG(value)) > 500 AS is_spike，再在外层 WHERE is_spike 过滤（注意：需用子查询或 CTE，因别名不能在同级 WHERE 用）

真正难的不是写出 LAG()，而是确认排序逻辑是否覆盖所有业务边界——比如跨天、跨区、时区转换、批量导入导致的时间戳乱序。这些地方一松懈，突变检测就变成随机抽查。