窗口函数计算同比更简洁但需数据库支持MySQL 8.0+/PG 11+/SQL Server 2012+，LAG(sum_amount,12)可直接取上年同月值；老版本需用自关联JOIN并严格聚合与匹配周期，同时用NULLIF处理分母为0，并确保时间口径统一。
用窗口函数算同比更简洁，但得确保数据库版本支持
MySQL 8.0+、PostgreSQL 11+、SQL Server 2012+ 支持 LAG() 或 LEAD()，可直接按时间维度错位取值。比如统计每月销售额同比（相比上一年同月），只要一行 LAG(sum_amount, 12) OVER (PARTITION BY month ORDER BY year) 就能拿到去年同月值。老版本 MySQL（如 5.7）不支持窗口函数，强行用会报错 ERROR 1064: You have an error in your SQL syntax。
实操建议：
- 先查数据库版本：
SELECT VERSION(); - 确认时间字段是否规整——必须能唯一标识“年+月”，推荐用
DATE_FORMAT(order_date, '%Y-%m')或CONCAT(YEAR(order_date), '-', LPAD(MONTH(order_date), 2, '0'))统一格式 - 如果原始数据含多天，务必先聚合再开窗，否则
LAG()会在日粒度上错位，导致同比值对应错月份
自关联实现同比更通用，但容易写成笛卡尔积
核心思路是把当前月表和去年同月表做 JOIN，例如 t1.year = t2.year + 1 AND t1.month = t2.month。看似简单，但常见错误是漏加分组条件或没预聚合，导致一条记录连出多条，最终求和翻倍。
实操建议：
- 必须先对原始表按时间粒度聚合（如
GROUP BY YEAR(order_date), MONTH(order_date)），再拿结果集自关联 - JOIN 条件要严格匹配周期偏移：年份差为 1，月份相同；若用季度，就得用
QUARTER(order_date)+YEAR(order_date)联合判断 - 注意 NULL 处理：去年同月无数据时，关联结果为 NULL，建议用
COALESCE(t2.amount, 0)避免同比计算中断
同比计算的分母为 0 时，NULL 比报错更安全
当去年同月销售额为 0，直接写 (t1.amount - t2.amount) / t2.amount 会触发除零错误（MySQL 报 ERROR 1365: Division by 0，PostgreSQL 报 division by zero）。窗口函数里同样适用。
实操建议：
- 统一用
NULLIF(t2.amount, 0)替换分母，让除零变NULL - 若业务要求显示“-”或“N/A”，再套一层
COALESCE(ROUND((t1.amount - t2.amount) / NULLIF(t2.amount, 0), 4), 'N/A') - 不要用
CASE WHEN t2.amount = 0 THEN 0 ELSE ... END，因为 0 增长率语义错误（基数为 0 时同比无意义）
时间维度不连续时，窗口函数比自关联更难排查问题
如果某个月缺数据（比如 2023-02 没订单），LAG(sum_amount, 12) 会跳到 2022-02 的前一个非空值（可能是 2022-01），造成同比错配。而自关联因显式指定 t1.year = t2.year + 1，缺月就自然无匹配行，结果为 NULL，反而更容易发现数据断层。
实操建议：
- 窗口函数方案上线前，先跑
SELECT DISTINCT CONCAT(year, '-', LPAD(month, 2, '0')) FROM sales GROUP BY year, month ORDER BY 1检查时间连续性 - 若存在断点，优先补全时间维度（用日历表
LEFT JOIN），再计算同比，别依赖窗口函数自动跳过 - 自关联虽啰嗦，但在数据质量不可控的生产环境里，逻辑更透明、异常更易定位
真正麻烦的不是语法选哪个，而是时间口径对齐——销售日期、发货日期、财务入账日期，选错一个，同比数字就全偏了。这个得跟业务方当面拍板，代码改不了定义问题。
