同比是与去年同期比较（如2024年3月vs2023年3月），环比是与上一周期比较（如2024年3月vs2024年2月）；SQL中需依数据库特性用DATE_SUB、LAG或JOIN实现，注意日期对齐、缺数处理及业务口径适配。
什么是同比和环比，SQL里怎么定义时间对比关系
同比是和去年同期比（比如2024年3月 vs 2023年3月），环比是和上一周期比（比如2024年3月 vs 2024年2月）。关键不是“叫什么”，而是你数据库里的时间字段是否能准确表达“年份偏移”或“月份偏移”。DATE_SUB、ADD_MONTHS、LAG 这些函数行为因数据库而异，MySQL、PostgreSQL、Oracle、ClickHouse 各自处理方式不同，不能直接套用。
- MySQL 8.0+ 支持
LAG，但不原生支持按年对齐的窗口帧；得靠DATE_SUB(<code>date_col, INTERVAL 1 YEAR) 手动构造关联条件 - PostgreSQL 用
LAG(<code>value) OVER (PARTITION BYyearORDER BYmonth) 只能做环比；同比必须用JOIN或子查询关联去年同月 - Oracle 和 ClickHouse 对
ADD_MONTHS/toRelativeMonthNum支持更稳，但要注意时区和月末日期（比如2023年1月31日 → 2024年1月31日在某些库会变成2024年2月1日）
用 LAG 算环比：简单但有陷阱
LAG 是最常用也最容易出错的方式。它只看排序顺序，不校验时间是否真“相邻”。
SELECT month, sales, LAG(sales) OVER (ORDER BY month) AS prev_month_sales, ROUND((sales - LAG(sales) OVER (ORDER BY month)) / NULLIF(LAG(sales) OVER (ORDER BY month), 0), 4) AS mom_rate FROM monthly_sales;
- 如果数据缺某个月（比如2024-02缺失），
LAG会跳到2024-01，算出来的是“隔月环比”，不是真正的环比 -
NULLIF必须加，否则除零报错：division by zero -
ORDER BY month要确保month是标准日期类型（如DATE或TEXT格式为'2024-03'），不能是'3月'这种中文字符串
用 JOIN 算同比：可靠但要小心日期对齐
同比必须严格匹配“年份-月份”维度，推荐显式 JOIN，而不是依赖窗口函数。
SELECT cur.month, cur.sales AS cur_sales, lastyear.sales AS last_year_sales, ROUND((cur.sales - lastyear.sales) / NULLIF(lastyear.sales, 0), 4) AS yoy_rate FROM monthly_sales cur LEFT JOIN monthly_sales lastyear ON YEAR(cur.month) = YEAR(lastyear.month) + 1 AND MONTH(cur.month) = MONTH(lastyear.month);
-
YEAR/MONTH函数在 MySQL 中可用，PostgreSQL 得用EXTRACT(YEAR FROM cur.month) - 用
LEFT JOIN而不是INNER JOIN，否则2023年没有的数据会导致2024年对应月份被丢弃 - 如果你的
month是字符串（如'2024-03'），可以用SUBSTR(cur.month, 1, 4)和SUBSTR(cur.month, 6, 2)提取年月，避免函数不可移植
复杂点在于：业务口径 vs 技术实现
真实场景中，“同比”可能要求：
- 自然日同比（2024-03-01 ~ 2024-03-31 vs 2023-03-01 ~ 2023-03-31）
- 财务周期同比（比如财年从4月开始，2024财年Q2 = 2024-04 ~ 2024-06）
- 工作日同比（剔除节假日，需额外日历表 JOIN）
这些没法靠一个 LAG 或一次 JOIN 解决。最稳妥的做法是：先把原始明细按业务规则聚合出标准周期表（带 period_id、period_type、ref_period 字段），再在这个宽表上做关联计算。否则每次改口径都要重写 SQL。
