LAG和LEAD是需配合OVER子句使用的窗口函数，参数为LAG(value,offset,default)，offset默认为1，default处理越界；必须用ORDER BY确定行序，且offset须为常量；分区可选，但环比计算通常无需PARTITION BY。
LAG 和 LEAD 函数的基本用法与参数含义
LAG 和 LEAD 是标准 SQL 窗口函数，用于访问当前行前（或后）第 N 行的值。它们必须配合 OVER 子句使用，且关键参数顺序是：LAG(value, offset, default) —— 其中 offset 默认为 1，default 在越界时返回（比如第一行调用 LAG 时无上一行，默认返回 NULL，除非显式指定 default）。
常见错误是忽略 ORDER BY：没有它，窗口无法确定“上一行”是谁，结果不可靠甚至报错（如 PostgreSQL 会直接拒绝执行）。另外，OFFSET 必须是常量表达式，不能是列名或子查询。
-
LAG(sales, 1)取前 1 行的sales值 -
LEAD(sales, 2, 0)取后 2 行的sales值，越界时返回 0 - 分区（
PARTITION BY）可选，但按时间序列算环比时通常不需要分组，除非你要分别计算每个产品/地区的环比
计算环比增长率的核心公式与 NULL 处理
环比 = (本期值 − 上期值) / 上期值。直接套用 LAG 得到上期值后，必须处理两种 NULL 场景：首行的 LAG 结果为 NULL；上期值为 0 会导致除零错误。
不要写成 (sales - LAG(sales)) / LAG(sales) —— 这会计算两次 LAG，效率低且难以控制 NULL。推荐用子查询或 CTE 提前计算出上期值，再统一处理：
SELECT
month,
sales,
CASE
WHEN prev_sales IS NULL OR prev_sales = 0 THEN NULL
ELSE ROUND((sales - prev_sales)::NUMERIC / prev_sales, 4)
END AS mom_growth
FROM (
SELECT
month,
sales,
LAG(sales) OVER (ORDER BY month) AS prev_sales
FROM sales_data
) t;-
ROUND(..., 4)避免浮点精度干扰判断 - 类型转换如
::NUMERIC（PostgreSQL）或CAST(... AS DECIMAL)（MySQL/SQL Server）防止整数除法截断 - 首月的
mom_growth必为 NULL，这是合理行为，不是 bug
不同数据库对日期排序和数据类型的兼容性细节
环比依赖严格的时间顺序，但各数据库对 ORDER BY 的健壮性不同。例如 MySQL 8.0+ 支持 ORDER BY date_col，但若 date_col 有重复值（同天多条记录），LAG 返回哪一行不确定 —— 必须加次级排序，如 ORDER BY date_col, id。
- PostgreSQL：支持
DATE、TIMESTAMP直接排序，无问题 - SQL Server：
LAG要求ORDER BY列有唯一性保证，否则可能跳行；建议加ROW_NUMBER()辅助 - BigQuery：
ORDER BY允许表达式，但LAG(sales) OVER (ORDER BY PARSE_DATE('%Y%m', month_str))更安全，避免字符串 '202312' > '202401' 的字典序陷阱
性能陷阱：窗口函数在大表上的执行代价
LAG/LEAD 本身不慢，但整个窗口计算需扫描并排序全量数据。如果只查最近 12 个月，别在 OVER 子句里写 ORDER BY month 后再用 WHERE month >= '2023-01' —— 数据库很可能先排序全表再过滤，白白浪费 I/O。
- 先过滤再开窗：把条件下推到子查询里，如
SELECT ... FROM (SELECT * FROM sales_data WHERE month >= '2023-01') t WINDOW w AS (ORDER BY month) - 确保
month或时间字段上有索引（B-tree 类型），否则排序成本陡增 - 在 Hive/Spark SQL 中，
LAG会触发 shuffle，数据倾斜时表现更差；若分区键含年月，优先用PARTITION BY year_month缩小窗口范围
真正容易被忽略的是：环比值本身没有业务意义，除非你确认原始数据已去重、无异常冲正、且时间粒度一致（比如全是自然月，而非财务月或滚动 30 天）。这些清洗工作远比写对 LAG 更影响结果可信度。
