LAG和LEAD必须完整指定OVER子句中的PARTITION BY与ORDER BY，缺一不可：漏PARTITION BY会导致跨组错连，漏ORDER BY则报错或行为未定义。
LAG/LEAD 必须写全 OVER 子句，否则结果错乱或直接报错
这两个函数不是普通标量函数，脱离 OVER 就无法执行。漏掉 PARTITION BY 会导致跨组取值——比如用户 A 的第一笔订单，LAG 可能取到用户 B 的最后一笔；漏掉 ORDER BY 在 PostgreSQL 和 MySQL 8.0+ 中会报错 window function requires a valid ordering，SQL Server 则强制要求。
常见错误写法：LAG(amount) OVER (PARTITION BY user_id)（缺 ORDER BY）或 LAG(amount) OVER (ORDER BY sale_date)（缺 PARTITION BY）。
- 分组字段（如
user_id、product_id）必须进PARTITION BY - 排序字段（如
sale_date）必须进ORDER BY，且最好带唯一性补充（如id或create_at），避免时间重复导致非确定性结果 - 哪怕只做全局排序不需分组，也得写
OVER (ORDER BY id)，不能省略OVER
OFFSET 和 default 参数怎么设才安全
LAG(column, offset, default) 三个参数中，offset 默认是 1，default 并非所有数据库都支持：MySQL 8.0+ 不支持第三参数，必须用 COALESCE(LAG(), 0)；PostgreSQL 和 BigQuery 支持，可直接写 LAG(amount, 1, 0)。
偏移量不是“越小越好”——同比场景下，若按月粒度存数据（ym = 202301, 202302...），环比用 LAG(val, 1)，同比必须用 LAG(val, 12)；若用日期类型，则先统一生成周期标识再开窗，避免因天数差异错位。
- 别写
LAG(amount, 0)——等于直接引用列，无意义 - 慎用大
offset（如LAG(val, 1000)），在 ClickHouse 或旧版 Hive 上可能触发全分区 materialize，内存暴涨 -
default值类型要和原列一致：amount是DECIMAL，就别用字符串'0'
计算差值时 NULL 导致整列变空，怎么破
LAG 在分组首行、LEAD 在分组末行天然返回 NULL。一旦参与运算，比如 amount - LAG(amount)，结果直接为 NULL，后续 WHERE diff > 0 就把首/末行全过滤掉了。
最常用解法是用 COALESCE 显式兜底：amount - COALESCE(LAG(amount) OVER (...), 0)。但“补 0”是否合理，取决于业务语义——有些场景补自身更合适（COALESCE(LAG(amount), amount) 表示“首行视为无变化”）。
- 不要依赖隐式转换处理
NULL，尤其涉及除法（如增长率）时，NULL / x还是NULL - 若仅需判断是否存在变化，可用
CASE WHEN LAG(amount) IS NOT NULL THEN ... END显式隔离边界 - 在子查询里提前算好差值列，别在外部再套一层窗口函数，避免重复计算
为什么 WHERE 里不能直接用 LAG 结果
SQL 执行顺序是：WHERE → GROUP BY → HAVING → SELECT → 窗口函数计算 → ORDER BY。LAG 在 WHERE 阶段根本还没算出来，所以 WHERE LAG(amount) > 100 语法非法。
正确做法只有两种：要么包一层子查询，要么用 CTE。例如：
SELECT * FROM (
SELECT user_id, order_time, amount,
amount - LAG(amount) OVER (PARTITION BY user_id ORDER BY order_time) AS diff
FROM orders
) t
WHERE t.diff > 500;- 别试图用变量模拟（如 MySQL 5.7 的
@var），不可靠且难维护 - CTE 虽清晰，但在某些引擎（如旧版 Hive）中可能无法下推过滤条件，建议优先用子查询并确保外层
WHERE能命中索引字段 - 如果只是想筛出“有下降记录”的用户，别在明细层
WHERE diff ，改用 <code>EXISTS或聚合后判断，性能更好
实际用起来最易被忽略的点是：排序键的唯一性不是“可选优化”，而是行为稳定性的底线。哪怕业务上认为时间不会重复，日志批量写入、毫秒级时间戳截断、时区转换都可能导致 ORDER BY event_time 产出非确定顺序——最终 LAG 每次跑结果都不一样。
