SQL中计算环比必须用LAG()配合ORDER BY和PARTITION BY，不能仅靠GROUP BY或聚合函数；典型结构是内层GROUP BY聚合、外层窗口函数计算差值与增长率，并用NULLIF防除零。
SQL中计算环比必须用LAG()配合GROUP BY
环比本质是「当前组值减去上期同组值」，不能只靠SUM()或AVG()这类聚合函数完成。必须先按时间维度排序分组，再用窗口函数取前一行数据。常见错误是直接在GROUP BY后套LAG()却不加ORDER BY，导致结果随机——LAG()默认不保证顺序，必须显式声明ORDER BY子句。
典型写法是：先用GROUP BY聚合出各时间段（如每月销售额），再用外层查询套LAG()计算差值。注意LAG()的第二个参数是偏移量（通常为1），第三个参数是缺失时的默认值（建议设为0或NULL，避免隐式类型转换）。
- 时间字段必须可排序（如
DATE、INT年月码），字符串格式的“202401”要转成数字或用TO_DATE()处理 - 若分组含多维（如按地区+月份），
PARTITION BY需包含所有非时间维度，否则跨地区拉取上月数据 - MySQL 8.0+、PostgreSQL、SQL Server 2012+ 支持；旧版MySQL需用自连接模拟，性能差且易出错
同比计算依赖DATE_SUB()或日期运算对齐周期
同比是「当前期与去年同期比较」，关键在于准确生成「去年同月/同日」的时间基准。不能简单用WHERE year = year - 1，因为分组后原始行已丢失。正确做法是在窗口函数中用日期函数构造同比参照点，再用LEFT JOIN或LAG()匹配。
例如按月统计时，用DATE_SUB(month_date, INTERVAL 1 YEAR)生成去年同月，在JOIN条件中关联；或用LAG(value, 12) OVER (PARTITION BY region ORDER BY year_month)（前提是数据严格按月连续无缺失）。后者更简洁，但要求12个月数据完整，缺月会导致错位。
- PostgreSQL用
(month_date - INTERVAL '1 year')，SQL Server用DATEADD(YEAR, -1, month_date) - 如果原始数据是日粒度但需月同比，先用
GROUP BY YEAR(date), MONTH(date)聚合，再处理，别在窗口里对日数据直接减365天 - 年初1月的同比会引用上年1月，但若数据库里没有上年数据，
LAG()返回NULL，需用COALESCE()兜底
聚合后计算环比/同比的典型SQL结构
必须分两层：内层GROUP BY做基础聚合，外层加窗口函数算变化率。直接在GROUP BY里写LAG()会报错（多数数据库不允许聚合函数与窗口函数混用在同一层级）。
SELECT region, ym, sales, sales - LAG(sales, 1) OVER (PARTITION BY region ORDER BY ym) AS mom_diff, ROUND((sales - LAG(sales, 12) OVER (PARTITION BY region ORDER BY ym)) / NULLIF(LAG(sales, 12) OVER (PARTITION BY region ORDER BY ym), 0), 4) AS yoy_rate FROM ( SELECT region, DATE_FORMAT(order_date, '%Y%m') AS ym, SUM(amount) AS sales FROM orders GROUP BY region, DATE_FORMAT(order_date, '%Y%m') ) t
注意NULLIF()防除零，ROUND()控制小数位。若用AVG()等其他聚合，替换内层SUM()即可，逻辑不变。
容易被忽略的边界问题
真实业务中，环比同比最常崩在时间断点上：比如2月只有28天，但去年2月29日有数据，或者促销期数据突增导致分母极小。这些不会报错，但结果失真。
- 检查时间维度是否连续：用
SELECT MIN(ym), MAX(ym), COUNT(*) FROM (...) t对比理论月份数，缺月要补0（用GENERATE_SERIES或递归CTE） - 同比分母为0时，
NULLIF()只解决除零，但业务上可能需要标记为“新业务线”而非跳过 - 跨年计算时，Oracle的
ADD_MONTHS()比INTERVAL更准（自动处理2月天数），而SQLite无原生日期函数，得用strftime()硬拼
时间对齐永远比聚合函数本身更耗精力。
