直接用join做同比环比容易出错，因为join本身无时间偏移逻辑，数据缺失时left join补null、inner join丢行均导致失真；必须先对齐时间维度、聚合后再计算。
为什么直接用 JOIN 做同比环比容易出错？
因为 SQL 的 JOIN 本身不带时间偏移逻辑，强行用 ON t1.date = t2.date 关联“本年 vs 去年”时，若某天数据缺失，LEFT JOIN 会补 NULL，INNER JOIN 则直接丢行——这两种都导致计算结果失真。真正可靠的同比环比，必须先确保时间维度对齐，再聚合，最后计算差值或比率。
用 LAG() + WINDOW 配合 JOIN 处理不规则日期
当业务日期不连续（如只统计工作日、节假日跳过），硬写 t1.date = DATE_SUB(t2.date, INTERVAL 1 YEAR) 会漏掉非对齐日。更稳的做法是：先用窗口函数生成“上期值”，再和主表 JOIN 补充字段，避免关联断裂。
- 先按时间排序，用
LAG(sales_amt, 1) OVER (PARTITION BY region ORDER BY dt)算前一日销售额（环比） - 用
LAG(sales_amt, 365) OVER (PARTITION BY region ORDER BY dt)粗略取去年同日（仅适用于每日全量且无缺失场景） - 若需严格同比（如 2024-03-15 对比 2023-03-15），建议先构造日期维表，
LEFT JOIN时用ON fact.dt = dim.dt AND dim.year_offset = 1，把“找去年同日”变成查表动作
多维分组下 JOIN 导致的笛卡尔爆炸风险
报表常需按 region、product_type、channel 多级分组做同比。若在 JOIN 前未聚合，而是拿明细表直接连维表，极易因粒度不一致引发重复计数。比如订单明细 × 日期维 × 地区维，三者主键未对齐就 JOIN，结果行数可能翻几倍。
- 务必先
GROUP BY明细表到目标粒度（如按天+地区+品类汇总销售额） - 日期维表要包含
dt、year_ago_dt、last_week_dt等预计算列，避免在ON条件里反复调用DATE_SUB() - 连接时用
USING (dt)或明确ON cur.dt = last.year_ago_dt，禁止ON cur.region = last.region AND cur.dt >= DATE_SUB(last.dt, INTERVAL 1 DAY)这类范围条件——它会触发嵌套循环，性能骤降
MySQL 8.0+ 和 PostgreSQL 中的替代方案对比
MySQL 8.0 起支持窗口函数，但不支持 RANGE BETWEEN INTERVAL '1 year' PRECEDING 这种动态范围；PostgreSQL 支持更好，但多数 BI 工具仍倾向用预聚合 + JOIN 保证兼容性。实际落地时，别迷信“一条 SQL 解决所有”，该拆就拆。
- MySQL：优先用
LAG()+ 子查询构造同比列，再JOIN维度信息 - PostgreSQL：可用
WITH RECURSIVE补齐缺失日期，但报表场景更推荐物化日期维表 - 注意
NULL处理：同比值为NULL时，COALESCE(yoy_ratio, 0)不够严谨——应区分“无去年同期数据”和“去年同期为 0”，后者除零会报错，得用NULLIF(denominator, 0)
真正卡住人的从来不是语法，而是“哪一层该聚合”“哪个 NULL 该保留”“日期对齐是以日历日为准，还是以业务周期为准”。这些判断没法靠 JOIN 自动完成，得看清楚上游数据到底怎么来的。
