要拿到“下一期”即去年同期值，需将时间转为整数序号（如年×12+月），再用LEAD(value, 12) OVER (ORDER BY 序号)；必须预处理时间字段、补全缺失期、避免GROUP BY后直接用窗口函数。
LEAD() 怎么写才能拿到“下一期”的值？
直接用 LEAD() 拿同期（比如去年同月）数据，不能只靠默认偏移量 1。它默认取的是**排序后紧邻的下一行**，不是日历意义上的“去年同期”。必须配合 ORDER BY 和窗口帧定义，把时间字段（如 year_month 或 date）转成可排序序列，并确保数据按时间连续、无缺失。
常见错误是：没做预处理就直接 LEAD(sales, 1) OVER (ORDER BY date)，结果拿的是下一天，不是下一年同月。
- 先保证时间字段是标准日期类型（
DATE或TEXT格式统一为'YYYY-MM'），避免字符串排序错乱 - 用
TO_CHAR(date, 'YYYY-MM')或DATE_TRUNC('month', date)归一化周期单位 -
LEAD()的第二个参数填偏移行数，但前提是——这些行必须对应“上年同月”在排序序列中的位置
怎么让 LEAD() 对应“去年同月”而不是“下一行”？
核心是构造一个能反映“年份差+月份对齐”的排序键。最稳妥的做法是把时间转换成整数序号，例如 EXTRACT(YEAR FROM date) * 12 + EXTRACT(MONTH FROM date)，这样 2023-01 → 24276，2024-01 → 24288，差正好是 12。
然后用这个序号排序，再用 LEAD(value, 12) 就能精准跳到去年同月。
SELECT
date,
sales,
LEAD(sales, 12) OVER (ORDER BY year_month_seq) AS sales_ly,
ROUND((sales - LEAD(sales, 12) OVER (ORDER BY year_month_seq)) / NULLIF(LEAD(sales, 12) OVER (ORDER BY year_month_seq), 0), 4) AS yoy_rate
FROM (
SELECT
date,
sales,
EXTRACT(YEAR FROM date) * 12 + EXTRACT(MONTH FROM date) AS year_month_seq
FROM sales_data
WHERE date >= '2022-01-01'
) t;注意：NULLIF(..., 0) 防止除零；ROUND(..., 4) 控制小数位；LEAD() 返回 NULL 是正常的（开头12个月没同期数据），别误判为逻辑错误。
为什么 GROUP BY 后不能直接套 LEAD()？
LEAD() 是窗口函数，必须在窗口上下文中执行，不能出现在 GROUP BY 聚合后的查询层级。如果你先按 product_id, year_month 分组求了月度销售额，再想算同比增长——得把 LEAD() 放在聚合之后的子查询或 CTE 里，否则会报错 column "sales" must appear in the GROUP BY clause or be used in an aggregate function。
- 错误写法：
SELECT product_id, year_month, SUM(sales), LEAD(SUM(sales), 12) OVER (...) FROM t GROUP BY product_id, year_month - 正确顺序：先聚合 → 再用 CTE 或子查询包一层 → 在外层开窗口
- 多维度分析时（如按地区+产品），
PARTITION BY region, product_id必须加，否则跨区域混算
性能和边界情况要注意什么？
大表上跑 LEAD() 窗口函数本身不慢，但排序成本高。如果没在 ORDER BY 字段建索引，全表扫描+排序会显著拖慢响应。
- 务必在用于排序的字段（如
year_month_seq或date）上建索引 - 数据有缺失月份？
LEAD(sales, 12)会跳过空行，导致错位——这时得先用GENERATE_SERIES补全时间维度，再左连接原始数据 - 跨年但不同天数（如 2023-02-28 和 2024-02-29）？用
DATE_TRUNC('month', date)统一到月初，比直接减INTERVAL '1 year'更稳定
真正麻烦的不是函数怎么写，而是时间对齐逻辑是否鲁棒——补全、截断、时区、业务定义（财年 vs 自然年），这些才是后期查不出数的根源。
