同比计算需用原生年份偏移函数而非减365天，按月统计应先对齐年份边界再拼接月份，mysql中date_sub安全处理2月29日，字符串日期宜直接替换年份；where条件须覆盖当前周期及去年同期完整区间；同比公式需用nullif防除零，且不补0以免失真；各库日期逻辑差异大，须针对验证。
SQL里怎么写同比计算的日期逻辑
同比增长率本质是「当前周期值减去去年同期值，再除以去年同期值」，关键在准确取到“去年同期”。不同数据库的日期函数差异大，直接套用 DATE_SUB 或 ADD_MONTHS 很容易错——比如2月29日没去年对应日、跨年时区偏移、或忽略闰年导致错位一整天。
实操建议：
- 优先用数据库原生的「年份偏移」函数，而不是简单减365天（
INTERVAL 365 DAY会漏掉闰日） - 对按月统计的场景，用
DATE_TRUNC('year', date_col)（PostgreSQL/Redshift）或TRUNC(date_col, 'YYYY')（Oracle）先对齐年份边界，再拼接月份 - MySQL 用户注意：
DATE_SUB(date_col, INTERVAL 1 YEAR)是安全的，它会自动处理2月29日 → 2月28日的降级逻辑 - 如果源数据是字符串（如
'2023-04'），别用STR_TO_DATE再减年——直接字符串替换更稳：CONCAT(YEAR(date_col) - 1, '-', LPAD(MONTH(date_col), 2, '0'))
写同比SQL时WHERE条件怎么避免数据截断
常见错误是 WHERE 过滤写成 WHERE dt >= '2023-01-01'，结果同比字段因缺少2022年数据而全为 NULL。同比不是单纯加一列，它依赖完整的历史窗口。
必须确保查询范围覆盖「当前周期 + 对应去年同期」两个完整区间：
- 若统计2023年4月同比，WHERE 至少要包含
dt BETWEEN '2022-04-01' AND '2023-04-30' - 用子查询或 CTE 预先生成时间维度表，比在主表上反复计算日期更可控
- 警惕分区表：Hive/Spark 中如果按
dt分区，WHERE 条件没覆盖去年分区，整个同比列就变成 NULL，且不报错
NULL值和除零问题怎么在同比公式里兜底
同比公式 (cur_val - last_year_val) / last_year_val 有两处硬伤：去年值为0导致除零，去年值缺失（NULL）导致整行变NULL。不能靠前端补0，得在SQL层拦截。
各库通用写法要点：
- 用
NULLIF(last_year_val, 0)替代直接除，避免除零错误（PostgreSQL/Redshift/BigQuery 支持；MySQL 用IF(last_year_val = 0, NULL, ...)） - 去年值为空时，同比应明确标为
NULL或'N/A'，而不是用COALESCE(last_year_val, 0)硬补0——这会让增长率失真 - 需要展示「无同比数据」状态时，加一列标识：
CASE WHEN last_year_val IS NULL THEN 'no_ly_data' ELSE 'valid' END
不同数据库的同比写法差异点在哪
同一逻辑，在MySQL、PostgreSQL、ClickHouse里写法可能差三倍代码量。核心分歧在窗口函数支持度和日期函数粒度。
- ClickHouse：用
toYear(toDate(dt)) = toYear(now()) - 1比addYears(dt, -1)更准，后者在某些版本对月末日期有偏移 - SQL Server：必须用
DATEFROMPARTS(YEAR(GETDATE())-1, MONTH(GETDATE()), 1)构造月初，不能依赖DATEADD(yy, -1, GETDATE())——它保留具体时间点，导致JOIN时精度错位 - BigQuery：
DATE_SUB(CURRENT_DATE(), INTERVAL 1 YEAR)安全，但聚合时若用EXTRACT(YEAR FROM dt)做分组，需额外处理跨年场景（如2023年1月实际对应2022年1月，但EXTRACT只取年份）
真正麻烦的不是函数名，而是每个数据库对「同一天」的定义——有的按日历日，有的按业务日，有的按UTC午夜。上线前一定拿已知的2023-02-29和2022-02-28两条记录跑下验证。
