同比是今年某期与去年同期比较（如2024-06 vs 2023-06），环比是本期与上期比较（如2024-06 vs 2024-05）；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 或忽略缺失月份导致偏移错位。
- 必须显式写
ORDER BY year_month（不能只靠 GROUP BY 的顺序） - 如果某月数据缺失（比如2024-02没记录），
LAG(value)会跳到 2024-01，造成“假环比”——建议先用日历表补全月份，或加判断：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-03 → 2023-03 是12行，但2024-01 → 2023-01 也是12行；而2024-02-29没有2023-02-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)做动态基准，但同比计算本身仍需对齐到相同月粒度
性能与兼容性：窗口函数不是万能的
PostgreSQL、SQL Server、Oracle、MySQL 8.0+ 都支持 LAG()，但旧版 MySQL（5.7 及以前）不支持，得用变量模拟或子查询自连接，性能差一个数量级。
即使支持窗口函数，也要警惕两点：
- 大表上
OVER (ORDER BY ...)会触发全局排序，没索引时极慢——务必在year_month列建索引 - 如果业务要求“自然月同比”，但原始数据是按天记录，别在窗口函数里直接
ORDER BY order_date，先用GROUP BY YEAR(order_date), MONTH(order_date)汇总，再套窗口函数 - 某些 BI 工具（如早期 Tableau）不识别嵌套窗口表达式，可能需拆成两层 CTE
真正卡住人的往往不是语法，而是时间维度是否对齐、空值如何解释、以及数据库版本悄悄限制了你能写的那几行代码。
