必须写全OVER子句：LAG(amount) OVER (PARTITION BY user_id ORDER BY event_time, id)且第三参数设默认值防NULL，否则报错或结果错乱。
LAG() 和 LEAD() 报错 “window function requires an OVER clause” 怎么办
这两个函数根本不能脱离 OVER 子句单独使用。写成 LAG(amount) 或 LEAD(date) 而不加 OVER，所有主流数据库（MySQL 8.0+、PostgreSQL、SQL Server、Hive）都会直接报错。
必须显式写出完整结构：LAG(amount) OVER (ORDER BY created_at)。漏掉 ORDER BY 同样危险——即使语法通过（如某些旧版 PostgreSQL 允许），结果也完全不可靠，因为“前一行”由物理存储顺序决定，每次查询都可能不同。
- 错误写法：
SELECT id, amount, LAG(amount) FROM sales - 正确写法：
SELECT id, amount, LAG(amount) OVER (ORDER BY created_at, id) AS prev_amount FROM sales - 排序字段建议带二级键（如
id），防时间戳重复导致窗口帧漂移
分组内计算差值时漏掉 PARTITION BY 会怎样
没加 PARTITION BY 就相当于把全表当一个大组排序。比如用户日志表里张三的最后一条记录，和李四的第一条记录紧挨着，LAG() 就会把李四的记录当成张三的“上一行”，差值完全失真。
典型场景是每个用户的操作序列、每台设备的传感器读数、每个商品的每日销量——只要业务逻辑要求“组内独立比对”，就必须加 PARTITION BY。
- 错误：只写
OVER (ORDER BY event_time)→ 全局混排 - 正确：写
OVER (PARTITION BY user_id ORDER BY event_time, id) - 注意
PARTITION BY字段类型要可比较，字符串时间（如'2026-08-27 14:22'）需转为DATETIME，否则分区失效
差值列大量为 NULL 是不是函数出问题了
不是。这是 SQL 三值逻辑的正常表现：LAG() 对每个分组第一行返回 NULL，LEAD() 对最后一行也返回 NULL；一旦参与运算（如 amount - LAG(amount)），整条结果就是 NULL。
别指望用 WHERE LAG(amount) IS NOT NULL 过滤——窗口函数在 WHERE 之后执行，语法直接报错。得换思路处理：
- 用第三参数设默认值：
LAG(amount, 1, 0) OVER (...)（MySQL 8.0+、PostgreSQL 15+、SQL Server 支持） - 用
COALESCE(LAG(amount), 0)兼容更老版本 - 用子查询或 CTE 提前算好偏移值，再在外层
WHERE过滤：SELECT * FROM (SELECT ..., LAG(amount) OVER (...) AS prev_amt FROM t) t2 WHERE t2.prev_amt IS NOT NULL
偏移量 offset 和默认值 default 的实际影响
offset 必须是常量整数，不能是列名或表达式（比如 LAG(amount, days_delay) 会报错）。它控制“跳几行”：LAG(amount, 2) 拿的是前两行的值，适合算同比（当前 vs 去年同日）或隔日变化。
default 看似可选，但生产环境强烈建议显式指定。隐式 NULL 会导致后续计算中断，尤其当差值列要进 SUM()、AVG() 或 BI 工具图表时，NULL 会被忽略或报错。
- 数值型字段推荐用
0：LAG(sales, 1, 0) - 日期字段可用
DATE '1970-01-01'或NULL（取决于业务含义） - 千万别混类型：
LAG(amount, 1, '0')可能触发隐式转换，造成精度丢失或报错
真正容易被忽略的是：当 ORDER BY 字段存在重复值（比如秒级时间戳、批量导入日志），数据库无法稳定确定“哪一行是前一行”，LAG() 结果可能每次查询都不一样——加二级排序和联合索引不是优化，而是保序刚需。
