lead/lag需数据库支持窗口函数且必须写over子句，order by不可省略；参数类型须一致，越界返回null或指定default；计算环比时应避免重复调用lag，优先用cte优化，并确保排序字段唯一以防错位。
LEAD 和 LAG 函数怎么写才不会报错
直接用 LEAD() 或 LAG() 却提示 “window function not supported” 或 “missing OVER clause”，通常是因为数据库不支持窗口函数（如 MySQL 5.7 及更早版本），或漏写了 OVER 子句。PostgreSQL、SQL Server、Oracle、MySQL 8.0+、BigQuery 和 Snowflake 都支持，但语法细节有差异。
必须显式指定排序依据，否则结果不可靠——窗口函数依赖行序，没 ORDER BY 就等于随机取值。
-
LAG(column, offset, default)：取当前行向上 offset 行的值；offset 默认为 1，default 是越界时返回值（如首行无上一行） -
LEAD(column, offset, default)：取当前行向下 offset 行的值；末行越界时返回 default - 所有参数都必须是同一类型，比如
LAG(sales)返回数值，就不能直接和字符串拼接
计算环比增长率的典型写法
环比 =（本期值 − 上期值）/ 上期值，核心是用 LAG() 拿到“上期值”。注意除零和 NULL 安全：上期值为 0 或 NULL 时，结果会变成 NULL 或报错（如 PostgreSQL 的 division by zero）。
以按月销售数据为例：
SELECT
month,
sales,
LAG(sales) OVER (ORDER BY month) AS prev_sales,
CASE
WHEN LAG(sales) OVER (ORDER BY month) = 0 THEN NULL
WHEN LAG(sales) OVER (ORDER BY month) IS NULL THEN NULL
ELSE (sales - LAG(sales) OVER (ORDER BY month)) * 1.0 / LAG(sales) OVER (ORDER BY month)
END AS mom_growth
FROM sales_data;
这里重复写了四次 LAG(sales) OVER (ORDER BY month)，虽然语义清晰，但执行效率低。实际建议用子查询或 CTE 提前算出 prev_sales，避免重复计算。
不同数据库对 NULL 和类型转换的处理差异
MySQL 8.0 对 LAG() 越界默认返回 NULL，而 SQL Server 允许指定 default 值（如 LAG(sales, 1, 0)）；PostgreSQL 则严格要求类型一致——如果 sales 是 INT，直接除会导致整数截断，必须显式转成 FLOAT 或乘 1.0。
- BigQuery 不支持在
CASE外直接用除法处理可能为 0 的分母，必须先判空 - SQLite 目前（v3.45）仍不支持窗口函数，强行用会报错
no such function: LAG - Oracle 中
LAG()第三个参数若为字符串，而列是数字，会隐式转类型失败，报ORA-00932
为什么环比结果看起来“错位”或全为 NULL
最常见原因是 ORDER BY 字段存在重复值（比如多条记录同属一个 month），导致窗口排序不稳定，LAG() 取到的“上期”可能是同月任意一条，而非逻辑上的前一个月。
- 解决方法：在
OVER子句中补充唯一排序键，例如ORDER BY month, id或ORDER BY year, month（确保 month 是完整日期或可排序字符串） - 如果原始数据里
month是字符串格式（如 '2024-1'），排序会错乱（'2024-10' DATE 类型或补零（'2024-01'） - 使用
PARTITION BY时（如分产品计算环比），务必确认分区字段和排序字段不冲突——例如PARTITION BY product ORDER BY month才合理，不能写成PARTITION BY month
真正容易被忽略的是时间粒度对齐：如果数据源本身缺失某个月份（比如 3 月没记录），LAG() 会跳到 2 月，造成“跳月环比”，而不是真正的连续月度对比。这种情况下，得先生成完整时间序列再 LEFT JOIN 补空。
