同比是与去年同期比较（如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 自然年度）。这些不提前清理，同比环比数字看着对，实际业务意义已经歪了。
