如何用SQL实现数据同比环比分析：掌握窗口函数与偏移函数
先明确一个核心概念：同比是今年某期与去年同期比较（例如2024年6月对比2023年6月），而环比则是本期与上期比较（例如2024年6月对比2024年5月）。这里有个常见的思维误区，以为只用GROUP BY就能搞定——实际上，GROUP BY无法跨行取值，必须借助窗口函数LAG()配合ORDER BY year_month来实现。过程中，补全月份、处理NULL值以及考虑数据库版本的兼容性，都是绕不开的细节。
什么是同比和环比，为什么不能只用 GROUP BY
简单来说，同比看的是年度周期变化（今年6月 vs 去年6月），环比看的是相邻周期变化（今年6月 vs 今年5月）。问题来了，为什么单靠GROUP BY加上聚合函数行不通呢？因为它只能把数据“压扁”成一行行的汇总结果，就像一个只能汇总、不能回看的计算器，根本无法访问“隔壁”月份的具体数值。
所以，正确的思路需要分两步走：首先，按时间粒度（比如YEAR_MONTH）聚合出每一期的指标；然后，利用窗口函数在这个有序的结果集里进行“横向取数”。关键在于，核心逻辑不是如何分组，而是如何让当前行能够准确地拿到历史行的数据。
用 LAG() 实现环比，注意 ORDER BY 和 NULL 处理
LAG()函数是实现环比计算最直接的工具，但它对数据的有序性和完整性要求极高。最常见的两个坑，一是忘记指定排序，二是时间序列不连续导致偏移错位。
- 排序是硬性要求：必须显式地写出
ORDER BY year_month，不能依赖GROUP BY产生的默认顺序。 - 警惕数据缺失：如果2024年2月份的数据缺失了，那么
LAG(value)为2024年3月取到的“上月值”就会错误地指向2024年1月，造成“假环比”。建议的解决方案是，先用日历表补全所有月份，或者在查询中明确处理：LAG(value) OVER (ORDER BY year_month) AS prev_month_value。 - 小心除以零：对于首行数据，
LAG()会返回NULL。在计算环比增长率时，需要妥善处理：ROUND((value - LAG(value) OVER (ORDER BY year_month)) * 100.0 / NULLIF(LAG(value) OVER (ORDER BY year_month), 0), 2)。
用 DATE_SUB() + JOIN 或 LAG() 配合日期运算做同比
同比的难点在于，“去年同月”并不是一个固定的行偏移量。虽然从2024年3月到2023年3月是偏移12行，从2024年1月到2023年1月也是偏移12行，但遇到像2024年2月29日这样的日期，去年可能根本没有2月29日。因此，不能简单地使用LAG(value, 12)。
更稳妥的做法有以下两种：
- 方案一（推荐，更清晰）：先构造一个包含
year_month和year_month_last_year的维度表，然后通过自连接进行关联，连接条件类似：ON t1.year_month = DATE_FORMAT(DATE_SUB(t2.year_month, INTERVAL 1 YEAR), ‘%Y-%m’)。 - 方案二（简化版，有条件使用）：直接使用窗口函数配合日期计算，例如
LAG(value, 12) OVER (ORDER BY year_month)。但这要求数据必须严格按月连续且没有空档，否则极易出错。 - 另外，MySQL 8.0+ 的用户可以使用
DATE_SUB(CURDATE(), INTERVAL 1 YEAR)来动态获取基准日期，但请注意，同比计算的核心依然需要对齐到相同的月份粒度上。
性能与兼容性：窗口函数不是万能的
虽然LAG()等窗口函数在PostgreSQL、SQL Server、Oracle以及MySQL 8.0+中都已得到支持，但在旧版的MySQL（5.7及以前）中却无法使用。这时就不得不退而求其次，使用用户变量模拟或者复杂的子查询自连接来实现，性能往往会下降一个数量级。
即便数据库支持窗口函数，也有两点需要特别警惕：
- 性能陷阱：在大表上执行
OVER (ORDER BY …)会触发全局排序，如果没有合适的索引，查询速度会急剧下降。务必确保在year_month这类排序字段上建立了索引。 - 粒度对齐：如果业务需求是“自然月同比”，但原始数据是按天记录的，千万不要直接在窗口函数里
ORDER BY order_date。正确的做法是，先用GROUP BY YEAR(order_date), MONTH(order_date)按月份聚合，再在外层套用窗口函数进行计算。 - 工具兼容性：部分早期的商业智能（BI）工具（如某些Tableau版本）可能无法正确解析嵌套的窗口表达式，这时可能需要将查询拆分成两层公共表表达式（CTE）来分步实现。
说到底，真正卡住人的往往不是语法本身，而是时间维度是否严格对齐、空值应该如何合理解释，以及数据库版本在无形中给你划定的能力边界。把这些细节处理好，你的同比环比分析才能既准确又高效。
