LAG函数必须配合OVER(ORDER BY 排序列)才能正确取上一行值，否则结果不可控；首行无上一行返回NULL，需用COALESCE或CASE显式处理；排序字段须具确定性，避免重复值导致错乱。
LAG函数怎么写才能正确取上一行数值
直接用 LAG(column_name) 会返回 NULL（第一行没上一行），但很多人没意识到：不指定 ORDER BY 就根本没法定义“上一行”——SQL 表本身无序，窗口函数依赖显式排序。必须搭配 OVER (ORDER BY timestamp ASC) 或其他确定性排序字段，否则结果不可靠，甚至每次执行都不同。
常见错误是只写 LAG(value) 却忘了 OVER 子句，报错 Window function requires an OVER clause；或者用了 OVER () 空括号，触发默认无序行为，差值计算全乱。
- 排序字段必须有唯一性或足够区分度，比如
id或created_at，避免多行同值导致 LAG 取到非预期行 - 如果业务上允许“按时间戳+ID联合排序”，建议写成
OVER (ORDER BY event_time, id) - 需要处理首行 NULL 的差值，后续要用
ABS()前得先COALESCE(LAG(value), value)或直接过滤掉首行
计算波动值时 ABS(LAG() - value) 为什么总出 NULL
只要 LAG(value) 返回 NULL（即第一行），整个减法表达式就是 NULL，ABS(NULL) 还是 NULL。这不是 bug，是 SQL 三值逻辑的必然结果。想让首行也参与比较，得主动补默认值。
别用 WHERE diff IS NOT NULL 粗暴跳过——可能漏掉真正重要的首行突变点。更稳妥的做法是用 COALESCE 提前兜底：
SELECT id, value, ABS(value - COALESCE(LAG(value) OVER (ORDER BY id), value)) AS diff FROM metrics;
这里把首行的“上一行值”设为自身，差值恒为 0，方便后续统一阈值筛选（比如 WHERE diff > 100）。
- 如果业务要求首行不参与波动判断，就加
WHERE LAG(value) OVER (ORDER BY id) IS NOT NULL -
ABS()不解决 NULL，只处理负数；NULL 必须靠COALESCE、NULLIF或CASE WHEN干预 - 数值类型要一致，比如
LAG(int_col)减float_col可能触发隐式转换失败，显式转成同类型更稳
怎么设置阈值快速标出异常波动行
波动检测不是算完 diff 就结束，关键在“多大算异常”。硬编码 WHERE diff > 50 很危险——数据量一变、量纲一换，阈值就失效。推荐两种实操路径：
- 用百分比浮动：
ABS(value - LAG(value)) * 1.0 / NULLIF(LAG(value), 0) > 0.1（注意除零保护） - 用滚动统计基准：嵌套子查询先算近 N 行的
AVG()和STDDEV()，再判断当前值是否超出AVG ± 2*STDDEV - 业务场景简单时，直接加索引加速：对排序字段（如
created_at）和数值字段（如value）建复合索引，避免全表扫描
注意：窗口函数本身不走索引，但 ORDER BY 字段有索引能极大提升排序性能，尤其百万级以上表。
LAG在不同数据库里的坑要不要统一处理
MySQL 8.0+、PostgreSQL、SQL Server 都支持标准 LAG()，但 SQLite 和旧版 MySQL（
最简替代是自连接模拟上一行：
SELECT t1.id, t1.value, ABS(t1.value - t2.value) AS diff FROM metrics t1 LEFT JOIN metrics t2 ON t2.id = ( SELECT MAX(id) FROM metrics WHERE id < t1.id );
虽然慢，但兼容性拉满。如果数据量不大（
- Oracle 用户注意：
LAG()默认第三参数是 NULL，但可以写LAG(value, 1, 0)直接指定默认值，不用套COALESCE - BigQuery 中
LAG()支持IGNORE NULLS，适合中间有空值的序列 - 所有方案里，时间字段的精度（秒 vs 毫秒）和时区一致性最容易被忽略，查波动前先
SELECT MIN(created_at), MAX(created_at)看看有没有异常跳变
