lag()是分组同比唯一合理解法,需partition by+order by确保保组保序,年月字符串排序防歧义,用case处理null和除零,mysql

用 LAG() 拿上期分组值,别写自连接
分组同比的核心是:在同一分组内,把当前行和上一个时间周期的值拉到同一行做减法或除法。用 JOIN 或子查询关联上期数据,既慢又容易漏组(比如某组某月没数据,自连接就丢行)。LAG() 是唯一合理解法——它按指定顺序在分组内“回头看”,天然保组、保序、保全。
实操要点:
- 必须搭配
PARTITION BY+ORDER BY,否则跨组错位(例如所有品类混在一起排,手机销量可能被算成冰箱的“上期”) -
LAG(value, 1)的第二个参数是偏移量,同比固定为1;若需环比上上月,才改成2 - 注意
ORDER BY字段必须是时间维度且无重复,否则排序不确定,LAG()结果随机——用year_month字符串比用date更稳,避免同天多条记录
时间字段要标准化成可排序的年月格式
原始数据里常见 order_date 是 DATETIME 或 TEXT,直接 ORDER BY order_date 会出问题:比如 '2024-01-15' 和 '2024-02-03' 排序没问题,但一旦有 '2024/01/15' 或 'Jan 2024',ORDER BY 就失效,LAG() 拉错行。
正确做法是统一提取年月:
SELECT product, DATE_FORMAT(order_date, '%Y-%m') AS year_month, SUM(amount) AS sales FROM orders GROUP BY product, DATE_FORMAT(order_date, '%Y-%m')
然后在外层窗口函数中用这个 year_month 排序——它字符串可比、无歧义、不依赖时区。
同比计算时小心除零和 NULL
LAG() 对首期数据返回 NULL,直接做除法如 sales / LAG(sales) 会得 NULL;更危险的是,如果上期 sales 是 0,除法会报错(不同数据库行为不同:PostgreSQL 报错,MySQL 返回 NULL 或警告)。
安全写法用 CASE 控制:
CASE WHEN LAG(sales) OVER (PARTITION BY product ORDER BY year_month) = 0 THEN NULL WHEN LAG(sales) OVER (PARTITION BY product ORDER BY year_month) IS NULL THEN NULL ELSE ROUND((sales - LAG(sales) OVER (PARTITION BY product ORDER BY year_month)) / LAG(sales) OVER (PARTITION BY product ORDER BY year_month), 4) END AS yoy_rate
三个要点:
- 先判
IS NULL,再判= 0,顺序不能反(NULL = 0永远不成立) - 每个
LAG()都重复写完整表达式,别用别名——窗口函数不能在SELECT里引用同级别名 -
ROUND()控制小数位,避免浮点误差干扰业务判断
MySQL 8.0+ 和 PostgreSQL 没问题,旧版 MySQL 得绕开
如果你用的是 MySQL ,它不支持窗口函数,硬上 <code>LAG() 会报错 ERROR 1064。这时候别折腾模拟,直接换思路:用变量实现伪窗口逻辑,但只适用于单线程、单结果集场景,且排序必须绝对稳定。
更现实的选择是:
- 升级到
MySQL 8.0+(窗口函数已稳定三年以上) - 用应用层(Python/Java)做两遍聚合:第一次取全量分组时间序列,第二次按组逐个算同比——慢但可控
- 如果只是临时查,导出 CSV 用 Excel 的
OFFSET()或INDEX()+MATCH()拉上期值,比写错 SQL 更快
真正容易被忽略的不是语法,而是时间颗粒度对齐——比如你按自然月聚合,但销售系统里 1 月 31 日的订单可能计入 2 月财务周期,这种口径差异会导致同比数字看起来“突变”,查半天发现是业务定义没对齐。










