同比增长率是（本期值−同期值）/同期值，需严格匹配上年同一周期；lag(value,1)计算的是环比而非同比，易因数据缺失或分组不规整出错；正确方法是通过自连接或补全时间序列后用lag，并处理除零和null。
什么是同比增长率，为什么不能直接用LAG()？
同比增长率 = (本期值 - 同期值) / 同期值，核心是“同比”——必须匹配上一年同一周期（比如2024年3月 vs 2023年3月），而不是简单取上一行。很多人误用 LAG(value, 1)，结果算出来是环比（相邻月份），不是同比，尤其在数据缺失或分组不规整时，错误更隐蔽。
正确做法是：先按年、月（或季度）对齐时间维度，再通过自连接或窗口函数关联“当前周期”和“去年同一周期”。
用LEFT JOIN + 日期偏移计算同比（最稳，兼容所有SQL方言）
适用于 MySQL、PostgreSQL、SQL Server 等不支持复杂窗口帧的场景，逻辑清晰、易调试、可加索引优化。
- 把原始表按
year和month（或date_trunc('month', order_date)）聚合出每组每月销售额，记为t_curr - 构造去年同期表
t_prev：用DATE_SUB(t_curr.month_date, INTERVAL 1 YEAR)（MySQL）或t_curr.month_date - INTERVAL '1 year'（PostgreSQL）生成去年同月日期 -
LEFT JOIN t_curr ON ... = t_prev.month_date，确保即使去年没数据，本期仍保留（增长率显示为NULL或0） - 最后用
COALESCE((t_curr.amount - t_prev.amount) / NULLIF(t_prev.amount, 0), 0)避免除零和 NULL 传播
示例片段（PostgreSQL）：
SELECT
t_curr.year_month,
t_curr.group_name,
ROUND(
COALESCE((t_curr.total - t_prev.total) * 1.0 / NULLIF(t_prev.total, 0), 0),
4
) AS yoy_rate
FROM monthly_sales t_curr
LEFT JOIN monthly_sales t_prev
ON t_curr.group_name = t_prev.group_name
AND t_prev.year_month = t_curr.year_month - INTERVAL '1 year';
用窗口函数 + ROWS BETWEEN 与时间偏移（仅适用支持时间范围窗口的引擎）
BigQuery、Trino、某些新版 PostgreSQL 支持 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 结合时间列排序，但真正可靠的是用 LAG(value, 12) ——前提是数据严格按月连续、无缺失、且已按 year, month 排序并补全空档。
-
LAG(total, 12) OVER (PARTITION BY group_name ORDER BY year, month)只在“每月一条、无跳月”时才等价于同比；一旦缺2023年2月数据，LAG(..., 12)会取到2023年1月，结果错乱 - 若必须用 LAG，先用
GENERATE_SERIES（PostgreSQL）或UNION ALL补全所有年月组合，再 LEFT JOIN 原始数据，否则不要信LAG(..., 12) - Oracle 用户注意：
LAG(value, 12)的 offset 是行数，不是日历月，别被文档误导
分组后计算失败的三个典型信号
一跑就报错或结果全为 NULL，大概率卡在这几个点：
- 没对时间字段做归一化：用
order_date直接PARTITION BY EXTRACT(YEAR FROM order_date), EXTRACT(MONTH FROM order_date)，但不同年份的同月可能跨分组边界，导致LAG错位 - GROUP BY 漏掉分组键：比如按
region计算同比，却只GROUP BY EXTRACT(YEAR FROM date)，结果把所有地区混在一起算 - 除零未处理：
NULLIF(denominator, 0)必须加，否则 PostgreSQL 报division by zero，MySQL 返回NULL但不提示，容易误判为“没数据”
真正麻烦的不是写法，而是确认你的时间粒度是否一致、是否有业务定义的“自然年月”（比如财年4月起始）、以及去年同周期是否存在有效数据——这些没法靠SQL自动校验，得结合业务口径人工核对样本。
