环比是当前值与上一个周期(如上月)的差值或比率,核心在于按时间有序比较;不能直接用lag()是因为它不自动排序或分组,必须显式指定order by确保时序、partition by隔离业务维度,并处理null和除零问题。

什么是环比,为什么不能直接用LAG()就完事?
环比是当前值与上一个周期(比如上月、上周)的差值或比率,核心在于“按时间有序比较”。很多人一上来就写 LAG(value),结果发现数据乱序、分组错位、NULL 值干扰计算——根本原因是没指定 ORDER BY 和 PARTITION BY。窗口函数不自动按时间排序,也不默认按业务维度分组。
- 必须显式用
ORDER BY date(或ORDER BY year_month)确保时序正确 - 若有多条业务线(如不同
product_id),必须加PARTITION BY product_id,否则 A 产品的上月值可能被当成了 B 产品的“上期” -
LAG()默认返回NULL,直接做减法或除法会得NULL,需配合COALESCE()或条件过滤
SELECT date, sales, sales - LAG(sales) OVER (ORDER BY date) AS mom_diff, ROUND((sales / NULLIF(LAG(sales) OVER (ORDER BY date), 0)) - 1, 4) AS mom_rate FROM sales_data;
如何处理月初/年末断层导致的跨周期错误?
真实业务中,date 字段常为每日数据,但环比通常按月比。如果直接 ORDER BY date,12月31日的 LAG() 是12月30日,而非11月30日——这不是环比,是日环比。必须先聚合到月粒度,再计算。
- 先用
GROUP BY YEAR(date), MONTH(date)或DATE_FORMAT(date, '%Y-%m')汇总月度值 - 再在子查询或 CTE 中对聚合后结果开窗,
ORDER BY year_month - 避免在原始明细表上直接开窗算“月环比”,否则逻辑必然错
WITH monthly AS (
SELECT
DATE_FORMAT(order_date, '%Y-%m') AS year_month,
SUM(amount) AS total_sales
FROM orders
GROUP BY DATE_FORMAT(order_date, '%Y-%m')
)
SELECT
year_month,
total_sales,
total_sales - LAG(total_sales) OVER (ORDER BY year_month) AS mom_diff
FROM monthly;
MySQL 8.0+ 和 PostgreSQL 的 LAG() 行为差异在哪?
虽然语法一致,但两个数据库对 LAG(expr, offset, default) 的 default 参数处理略有不同:
- MySQL:第三个参数
default在LAG()越界时(如首行无前值)直接返回该值,安全可用 - PostgreSQL:同样支持,但若省略
default且越界,返回NULL;而某些旧版本对NULLIF()和除零判断更敏感
关键实操建议:
- 统一写成
LAG(sales, 1, 0) OVER (...)明确兜底,避免首行NULL污染后续计算 - 算增长率时,永远用
NULLIF(LAG(...), 0)替代直接除,防止除零错误 - PostgreSQL 用户注意:
ROUND(x::numeric, 4)比隐式转换更稳,MySQL 则无需显式转类型
为什么用窗口函数比自连接更可靠?
有人用 LEFT JOIN t1 ON t1.date = DATE_SUB(t2.date, INTERVAL 1 MONTH) 算环比,问题不少:
- 日期不连续(如节假日无数据)时,JOIN 会漏掉整月,而
LAG()只看排序位置,不依赖日期是否连续 - 多维度分组(如按
region+product)时,自连接的 ON 条件极易写错或爆炸式膨胀 - 窗口函数天然支持任意偏移量(
LAG(sales, 3)算同比?只要ORDER BY正确即可)
真正要警惕的是:窗口函数依赖排序稳定性。如果 date 有重复值且未加二级排序(如 ORDER BY date, id),LAG() 返回哪一行不确定——这比语法错误更难排查。
别只盯着函数怎么写,先盯住 ORDER BY 是否唯一、是否符合业务周期、是否覆盖所有分组维度。其余都是细节。










