LAG()是窗口函数，只能用于SELECT或ORDER BY子句，必须搭配含ORDER BY的OVER()子句，不可用于WHERE或GROUP BY；MySQL 8.0+才支持，5.7需用自连接或子查询模拟。
LAG函数怎么写才不报错
直接用 LAG() 却提示 “window function is not allowed here”，说明你把它塞进了 WHERE 或 GROUP BY 里——LAG() 是窗口函数，只能出现在 SELECT 或 ORDER BY 中，不能用于过滤或分组逻辑。
常见错误场景：想“只取上一行值为 X 的记录”，结果在 WHERE 里写 WHERE LAG(value) OVER (...) = 'X'，这不行。得先用子查询或 CTE 把 LAG() 算出来，再在外层过滤。
实操建议：
-
LAG()必须搭配OVER()，且OVER()至少要含ORDER BY，否则结果无序、不可靠 - 默认取上 1 行，即
LAG(col)等价于LAG(col, 1)；想取上两行就写LAG(col, 2) - 第三参数是默认值，比如
LAG(amount, 1, 0)表示首行没有“上一行”，就填 0，不填则返回NULL
LAG和LEAD搞混了怎么办
查“上一行”却拿到下一行的值？大概率用了 LEAD() 而不是 LAG()。LAG() 往“过去”看（上），LEAD() 往“未来”看（下），名字和方向刚好对应英文原意。
容易踩的坑：
- 在时间序列中按
ORDER BY created_at DESC排序时，LAG()拿到的是更晚的时间点（因为“上一行”在排序后其实是下一条时间记录）——这不是函数错了，是你排序逻辑和业务理解反了 - 别依赖列名猜函数行为，每次用都默念一遍：“L 是 Last，Lag = look back”
- 如果业务要“对比当前和前一笔订单金额”，必须确保
ORDER BY order_time ASC，否则LAG()返回的不是你认为的“前一笔”
LAG在MySQL 5.7里根本不能用
执行 LAG() 直接报错 FUNCTION xxx.LAG does not exist？那是版本太老。窗口函数是 MySQL 8.0+ 才支持的特性，5.7 及之前只能绕开。
替代方案有限但可用：
- 用自连接：给原表加行号（通过变量或子查询），再关联
t1.row_num = t2.row_num + 1 - 用相关子查询：
(SELECT value FROM tbl t2 WHERE t2.id ，但数据量大时性能明显下降 - 如果用的是 MariaDB，确认版本 ≥ 10.2 —— 它比 MySQL 更早支持窗口函数
- PostgreSQL、SQL Server、Oracle、BigQuery 都原生支持，无需降级处理
为什么LAG结果全是NULL
不是数据问题，大概率是 OVER() 里漏了 PARTITION BY 或 ORDER BY，或者两者顺序/粒度不对。
典型现象：
- 全表没分区也没排序：
OVER()空着，数据库可能按任意物理顺序计算，首行永远 NULL，其余行也不稳定 - 写了
PARTITION BY user_id却忘了ORDER BY event_time：每个用户分区里行序不确定，LAG()不知道谁是“上一行” - 排序字段有大量重复值（如都是同一天），导致窗口内相对顺序未定义——加个唯一字段兜底，比如
ORDER BY event_time, id
复杂点在于：LAG() 的行为完全由 OVER() 定义，而不是表本身结构。哪怕数据看着“很顺”，只要 ORDER BY 不够唯一，结果就可能每次执行都不一样。
