SQL 如何计算同比与环比？

同比是与去年同期比较（如2024年3月 vs 2023年3月），环比是与上一周期比较（如2024年3月 vs 2024年2月）；sql中需用date_SUB或LAG精确对齐时间基准，避免仅按年过滤导致月份错配。

什么是同比和环比，SQL 里怎么定义时间基准

同比是跟去年同期比（比如 2024 年 3 月 vs 2023 年 3 月），环比是跟上一周期比（比如 2024 年 3 月 vs 2024 年 2 月）。关键不是“算差值”，而是先明确date字段怎么对齐——用DATE_SUB或ADD_MONTHS拉出对比期，再JOIN或LAG关联数据。

常见错误是直接用YEAR(date) = YEAR(NOW()) - 1过滤同比，但漏掉月份匹配，导致 2024-03 和 2023-01 被混在一起。必须同时约束年+月，或用日期运算生成精确对比日。

用 LAG 算环比最简洁，但要注意分区和排序

LAG适合按时间序列逐行取上一行值，不用JOIN，性能好、写法短。但它依赖ORDER BY严格有序，且必须PARTITION BY分组（比如按产品线、地区），否则跨组数据会串。

• 排序字段必须是可比较的时间单位：用DATE_FORMAT(order_date, '%Y-%m')比直接order_date更稳，避免同月多天干扰
• 偏移量填1是上月，填12是上年同月（可兼作同比，但不如显式日期运算清晰）
• 如果某月无数据，LAG返回NULL，需用COALESCE兜底，否则除零或空值传播

SELECT    DATE_FORMAT(order_date, '%Y-%m') AS ym,   SUM(amount) AS cur_month,   LAG(SUM(amount), 1) OVER (PARTITION BY 'all' ORDER BY DATE_FORMAT(order_date, '%Y-%m')) AS last_month,   ROUND((SUM(amount) - LAG(SUM(amount), 1) OVER (...)) / NULLIF(LAG(SUM(amount), 1) OVER (...), 0), 4) AS mom_rate FROM orders GROUP BY ym;

用 LEFT JOIN 算同比更可控，但得处理 NULL 和重复

显式构造同比日期后LEFT JOIN，逻辑直白，容易调试。问题在于：JOIN 条件稍有偏差就漏数据；若原始表有多个同月记录，不加GROUP BY会导致笛卡尔积；NULL出现在同比侧时，COALESCE或NULLIF必须套在除法外层。

• 生成同比日期推荐用DATE_SUB(order_date, INTERVAL 1 YEAR)，别用YEAR-1拼字符串——后者无法处理 2024-02-29 这种闰日
• JOIN 时两边都用DATE_FORMAT(..., '%Y-%m')对齐，避免因日粒度不同导致匹配失败
• 务必在 JOIN 后立刻GROUP BY，否则聚合前已膨胀

SELECT    cur.ym,   cur.total AS cur_total,   COALESCE(prev.total, 0) AS prev_total,   ROUND((cur.total - COALESCE(prev.total, 0)) / NULLIF(COALESCE(prev.total, 0), 0), 4) AS yoy_rate FROM (   SELECT DATE_FORMAT(order_date, '%Y-%m') AS ym, SUM(amount) AS total   FROM orders GROUP BY ym ) cur LEFT JOIN (   SELECT DATE_FORMAT(DATE_SUB(order_date, INTERVAL 1 YEAR), '%Y-%m') AS ym, SUM(amount) AS total   FROM orders GROUP BY ym ) prev ON cur.ym = prev.ym;

mysql 8.0+ 和 postgresql 的函数差异点

MySQL 8.0+ 支持LAG，但DATE_SUB对INTERVAL 1 YEAR的处理不如 PostgreSQL 的MAKE_INTERVAL或AGE稳健；PostgreSQL 中TO_CHAR(order_date, 'yyYY-MM')比 MySQL 的DATE_FORMAT更统一，且EXTRACT(YEAR FROM ...)配合EXTRACT(MONTH FROM ...)可避免格式化开销。

• MySQL 5.7 不支持窗口函数，只能用变量或子查询模拟LAG，易出错且不可并行
• PostgreSQL 中LAG(..., 1) OVER (ORDER BY order_date)默认按order_date精确到秒，若同秒有多条，需加id等唯一字段保序
• 所有数据库中，NULLIF(denominator, 0)比CASE WHEN denominator = 0 THEN NULL ELSE ... END更简短且语义明确

真正难的不是写出来，而是确认你的时间字段有没有时区偏移、是否包含未来日期、是否存在跨年汇总口径不一致（比如财务年度 vs 自然年度）。这些不提前清理，同比环比数字看着对，实际业务意义已经歪了。