lead函数适合计算环比增长率，因其可直接获取下一行值，避免自连接或子查询，简洁高效；需配合partition by和order by确保时序与分组正确，并用nullif防除零错误。
LEAD 函数为什么适合算环比增长率
因为 LEAD 能直接取「下一行」的值，不用自连接或子查询，写起来干净，执行也快。尤其在按时间排序后计算月度/季度指标变化时，它天然匹配“本期 vs 下期”的逻辑（注意：实际中常需配合 LAG 算同比或环比，但标题明确要 LEAD，我们就用它算“下期比本期涨多少”——比如预测类场景或倒序分析）。
常见错误是没加 ORDER BY 子句就用 LEAD，结果行顺序混乱，增长率全错；或者忽略 PARTITION BY 导致跨业务线混算。
- 必须在窗口函数中显式写
ORDER BY date（或等效时间字段），否则行为未定义 - 多维度指标（如分城市、分产品）必须加
PARTITION BY city, product，否则 A 城市 12 月会和 B 城市 1 月对比 -
LEAD(value, 1)默认取下 1 行，第二参数可改，第三参数可设默认值（如LEAD(sales, 1, 0)防 NULL）
写法示例：月度销售额增长率（LEAD 取下月值）
假设表 sales_monthly 有字段：ym（格式 '2024-01'）、region、amount。目标：每行显示「本月金额」和「下月比本月增长多少 %」。
SELECT
ym,
region,
amount,
LEAD(amount, 1) OVER (PARTITION BY region ORDER BY ym) AS next_amount,
ROUND(
(LEAD(amount, 1) OVER (PARTITION BY region ORDER BY ym) - amount) * 100.0 / NULLIF(amount, 0),
2
) AS growth_pct
FROM sales_monthly;
关键点：
-
NULLIF(amount, 0)防止除零错误——当本月为 0 时，分母变 NULL，整个表达式返回 NULL，比报错或得 INF 更安全 - 两次写
LEAD不影响性能，现代优化器会复用窗口计算结果 - 如果
ym是字符串，确保字典序等于时间序（如 '2024-01'
LEAD 和 LAG 混用时的典型陷阱
有人想“既看上月又看下月”，于是写 LAG(amount) OVER(...) AS last_amount 和 LEAD(amount) OVER(...) AS next_amount。这本身没问题，但要注意：两个函数的窗口定义必须完全一致（PARTITION BY 和 ORDER BY 字段、顺序、方向都相同），否则结果对不上行。
- 错误写法：
LAG(...) ORDER BY ym ASC+LEAD(...) ORDER BY ym DESC→ 行错位 - 更隐蔽的问题：一个用
ym，另一个用TO_DATE(ym, 'YYYY-MM')→ 类型隐式转换可能导致排序偏差 - 如果原始数据存在重复
ym值（如多条记录同月），ORDER BY ym不足以保证稳定排序，应补上唯一字段如ORDER BY ym, id
当 LEAD 返回 NULL 时怎么处理才合理
LEAD 在最后一行必然返回 NULL（没有“下一行”）。直接参与计算会导致整列 growth_pct 为 NULL。这不是 bug，是设计如此——但业务上往往需要标注“无下期数据”。
- 用
CASE WHEN next_amount IS NULL THEN 'final_period' ELSE ... END显式区分 - 避免用
COALESCE(LEAD(...), amount)把最后一条强行当成 0 增长——这会扭曲统计口径 - 如果要做趋势聚合（如“近三月平均增长率”），应在外部过滤掉
next_amount IS NULL的行，而不是填充
真正难的不是写对语法，而是想清楚：你算的是“已发生的变化”，还是“潜在的变化预期”——前者该用 LAG，后者才轮到 LEAD。别让函数选择掩盖了业务逻辑歧义。
