LAG()是分组同比唯一合理解法，需PARTITION BY+ORDER BY确保保组保序，年月字符串排序防歧义，用CASE处理NULL和除零，MySQL<8.0应升级或改用应用层计算。
用 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 < 8.0，它不支持窗口函数，硬上 LAG() 会报错 ERROR 1064。这时候别折腾模拟，直接换思路：用变量实现伪窗口逻辑，但只适用于单线程、单结果集场景，且排序必须绝对稳定。
更现实的选择是：
- 升级到
MySQL 8.0+（窗口函数已稳定三年以上） - 用应用层（Python/Java）做两遍聚合：第一次取全量分组时间序列，第二次按组逐个算同比——慢但可控
- 如果只是临时查，导出 CSV 用 Excel 的
OFFSET()或INDEX()+MATCH()拉上期值，比写错 SQL 更快
真正容易被忽略的不是语法，而是时间颗粒度对齐——比如你按自然月聚合，但销售系统里 1 月 31 日的订单可能计入 2 月财务周期，这种口径差异会导致同比数字看起来“突变”，查半天发现是业务定义没对齐。
