LAG函数必须配合ORDER BY的OVER子句才能稳定获取上一行值，否则结果不可控；需用COALESCE处理NULL，避免计算中断；性能瓶颈在排序字段索引缺失；阈值应参数化或存配置表，不可硬编码。

LAG函数怎么写才能拿到上一行的值

关键不是“用LAG”，而是OVER子句必须明确排序逻辑，否则结果完全不可控。数据库不保证物理行序，没ORDER BY就等于随机取上一行。

• 必须搭配ORDER BY，比如按时间戳ORDER BY event_time，不能只写OVER()
• 分区（PARTITION BY）要谨慎：监控用户行为波动时，通常按user_id分；但全量指标同比，就不能加PARTITION BY，否则每组内只跟自己比
• 默认偏移是1，想比前两小时值就写LAG(value, 2)，别漏参数

错误示例：LAG(metric) OVER () —— 这在PostgreSQL可能跑通，但结果每次执行都可能不同，线上预警绝对不能这么用。

用LAG算波动率时NULL值怎么处理

LAG第一行永远返回NULL，直接参与除法或减法会把整行变NULL，导致告警漏报。

• 用COALESCE(LAG(value), value)兜底最稳妥，意思是“没前值就用当前值”，避免波动率计算中断
• 如果业务要求必须有前值才计算（比如只监控连续两天的数据），就加WHERE LAG(value) IS NOT NULL，但要注意这会跳过首条记录
• 别用ISNULL或NVL——函数名因数据库而异，COALESCE是SQL标准，MySQL/PG/Oracle都支持

典型翻车点：写(value - LAG(value)) / LAG(value)，只要LAG返回NULL，整列都是NULL，看日志以为没数据，其实是被吞了。

实时预警场景下LAG性能为什么突然变差

LAG本身不慢，慢在OVER子句的排序和窗口范围。尤其当监控表每天新增千万级日志，又没建对索引时，查询从毫秒变分钟。

• 确保ORDER BY字段有索引，例如CREATE INDEX idx_events_time ON events(event_time)
• 避免在大宽表上直接LAG多个字段，先用子查询过滤出关键字段+时间+主键，再套LAG
• ClickHouse等列存库慎用ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，默认窗口已够用，显式声明反而触发全窗扫描

一个信号：EXPLAIN显示“Sort”节点占耗时80%以上，基本就是ORDER BY没走索引或者数据量超预期。

告警阈值该不该写死在SQL里

不该。把ABS((value - LAG(value)) / NULLIF(LAG(value), 0)) > 0.3这种硬编码塞进SQL，等于把业务规则和数据逻辑锁死，改个阈值就得发版。

• 用参数化方式传入阈值，比如通过应用层拼接WHERE delta_rate > ?，或用数据库变量（如MySQL的@alert_threshold）
• 更推荐把阈值存在配置表里，JOIN进来，这样运营同学也能自助调整，不用动SQL
• 注意NULLIF(LAG(value), 0)防除零，但别写成NULLIF(value, 0)——那是拿当前值去比，毫无意义

真正麻烦的是波动方向判断：跌30%要告警，涨50%却是正常促销。这时候LAG只是工具，业务语义得靠外层CASE或应用逻辑补全，SQL里堆太多条件反而难维护。