跨粒度数据关联在SQL分析中非常常见，但处理不当会让统计结果完全失真。比如订单明细表每天产生几千行销售记录，而月度目标表一个月只有一行，如果直接把两张表按月份等值关联，目标金额会被重复累加，最终汇总值可能膨胀几十倍。要解决这个问题，核心不是换一种JOIN写法，而是先把粗粒度数据拆成与事实表相同的细粒度，再执行关联。临时表在这个过程中承担了平摊和预计算的角色，既能保存拆分后的结果，也能避免重复计算。下面从粒度错配的成因开始，逐步给出按日期展开、按权重分配以及性能控制的SQL实现。
一、为什么不同粒度的表直接关联会出错
粒度描述的是表中一行数据代表的业务范围。事实表通常具有最细粒度，例如一行代表一次销售、一条日志、一次库存变动；而目标表、预算表、维度指标表往往按较粗粒度存储，例如按月、按地区、按品类汇总。等值JOIN要求关联键在两边唯一或至少一边唯一。当粗粒度表的一行对应事实表多行时，SQL会按笛卡尔积方式将粗粒度行复制到每一条明细上。这个行为不是SQL错误，而是关系代数的自然结果。
举一个典型例子：订单明细表 order_detail 有 order_id、sale_date、region、amount；月度目标表 month_target 有 month_id、region、target_amount。如果直接按月份和地区关联，目标金额 target_amount 会出现在每个订单行中。此时再对目标金额做 SUM，结果等于单月目标乘以该月订单行数，而不是目标本身。很多报表里目标完成率百分之几千，基本就是这个原因造成的。
下面这段查询就是一种典型的错误写法：
-- 错误示例：直接关联会造成目标金额复算
SELECT
od.region,
DATE_FORMAT(od.sale_date, '%Y%m') AS month_id,
SUM(od.amount) AS actual_amount,
SUM(mt.target_amount) AS target_amount,
SUM(od.amount) / NULLIF(SUM(mt.target_amount), 0) AS completion_rate
FROM order_detail od
JOIN month_target mt
ON mt.region = od.region
AND mt.month_id = DATE_FORMAT(od.sale_date, '%Y%m')
GROUP BY od.region, DATE_FORMAT(od.sale_date, '%Y%m');
这段SQL在语法上没有问题，但业务逻辑上犯了粒度不对齐的错误。目标行被订单行复制，导致目标金额参与聚合时被放大。解决这类问题的通用思路，就是把粗粒度的目标先平摊到细粒度，再与事实表关联。
二、利用临时表把月度目标平摊到天
临时表方案的核心是把粗粒度行拆成细粒度行。以月度目标拆成日目标为例，可以先把目标金额除以当月天数，得到每日目标，再把结果保存到临时表。后续事实表只需要按日期关联临时表，就能保证目标金额在日粒度上只出现一次，不会因为一对多关系而复算。
如果数据库支持递归CTE，生成日序列比较直接。先构造每个月份的开始日期、结束日期和天数，递归展开日期，然后计算日目标。不同数据库生成日期序列的函数不同，下面以PostgreSQL写法为例，MySQL 8.0可以把日期函数替换为 STR_TO_DATE 和 LAST_DAY，SQL Server则可以改用 DATEADD 和 EOMONTH。
-- 创建平摊到天的临时表
CREATE TEMP TABLE tmp_daily_target AS
WITH RECURSIVE date_expand AS (
SELECT
mt.region,
mt.month_id,
date_trunc('month', to_date(mt.month_id, 'YYYYMM'))::date AS dt,
(date_trunc('month', to_date(mt.month_id, 'YYYYMM')) + interval '1 month' - interval '1 day')::date AS month_end,
extract(day from (date_trunc('month', to_date(mt.month_id, 'YYYYMM')) + interval '1 month' - interval '1 day'))::int AS days_in_month,
mt.target_amount
FROM month_target mt
UNION ALL
SELECT
de.region,
de.month_id,
(de.dt + interval '1 day')::date AS dt,
de.month_end,
de.days_in_month,
de.target_amount
FROM date_expand de
WHERE de.dt < de.month_end
)
SELECT
dt,
region,
target_amount / days_in_month AS daily_target
FROM date_expand;
这段代码中的递归CTE分为两部分：锚点部分从 month_target 表生成月初、月末和当月天数；递归部分每次在现有日期上加一天，直到日期等于月末为止。由于 days_in_month 在递归过程中保持不变，最后用 target_amount / days_in_month 就能得到每日目标。如果目标按工作日而非自然日分摊，只需要把 days_in_month 替换为当月实际工作日数量，或者关联日历表判断是否工作日。
临时表落地后通常会加主键或索引。比如给 dt 和 region 建立复合索引，后续关联时会快很多。最终事实表关联可以写成：
SELECT
od.order_id,
od.sale_date,
td.daily_target
FROM order_detail od
JOIN tmp_daily_target td
ON td.dt = od.sale_date
AND td.region = od.region;
这样每个订单明细行只会匹配临时表中的一行日目标，目标金额不再被明细行数放大。整个拆分过程被限制在临时表中完成，主查询更简洁，也不容易因为逻辑复杂而写错关联条件。
三、按权重把目标分摊到门店或品类
很多业务场景中不仅日期粒度不一致，维度粒度也不一致。例如区域目标表按月存一行，但事实表按门店和日期记录销售。此时需要先把区域目标按门店权重平摊，再把门店月度目标继续拆到天。权重通常来自历史销售占比、门店数量、固定系数或业务录入的分配比例。
假设有两张表：region_month_target(month_id, region, target_amount) 和 store_weight(store_id, region, weight)。其中 weight 是门店在该区域的权重系数。要得到每个门店每月的目标，可以使用窗口函数对权重做归一化，避免手动先聚合权重占比再关联。
-- 按门店权重平摊区域目标，并保存到临时表
CREATE TEMP TABLE tmp_store_month_target AS
SELECT
sw.store_id,
sw.region,
rmt.month_id,
rmt.target_amount * (sw.weight / NULLIF(SUM(sw.weight) OVER (PARTITION BY rmt.region, rmt.month_id), 0)) AS store_target
FROM region_month_target rmt
JOIN store_weight sw
ON sw.region = rmt.region;
这段SQL利用 SUM(sw.weight) OVER (PARTITION BY rmt.region, rmt.month_id) 计算每个区域每个月的权重总和，再把每条门店权重除以总和，得到归一化比例。使用 NULLIF 是为了防止权重总和为零时出现除零错误。最终 store_target 已经是区域目标分摊到门店后的值，并且所有门店目标加起来应该等于原始区域目标。
如果还需要继续拆到门店天粒度，可以再次借助日期维表或日期临时表：
-- 继续平摊到门店天粒度
CREATE TEMP TABLE tmp_daily_store_target AS
SELECT
smt.store_id,
d.calendar_date,
smt.store_target / d.days_in_month AS daily_store_target
FROM tmp_store_month_target smt
JOIN date_dim d
ON d.month_id = smt.month_id;
这里 date_dim 是常见的日期维表，包含 calendar_date、month_id、days_in_month 等字段。把门店月度目标再除以当月天数，就得到了门店天粒度目标。采用临时表分步落地，可以随时检查中间结果，例如用 SUM(store_target) 验证是否与原始区域目标一致，避免分摊系数错误导致最终目标总额对不上。
四、临时表平摊方案在生产中的管理与优化
临时表虽然能解决粒度关联问题，但如果不对索引和统计信息做处理，性能可能变差。对于最终关联时按日期等值查询的场景，可以在临时表上创建单列或复合索引。例如：
CREATE INDEX idx_tmp_daily_target ON tmp_daily_target(region, dt);
在PostgreSQL中，创建索引后可以执行 ANALYZE tmp_daily_target; 让优化器获得更准确的统计信息。在MySQL中，如果临时表数据量较大，可能从MEMORY存储引擎转为InnoDB，此时更需要控制索引大小，避免临时表占用过多内存。
很多人喜欢把平摊逻辑写成多个CTE，但同一个CTE被多次引用时，优化器可能重复计算。临时表显式落地可以避免这个风险，也更适合批处理任务。如果数据库支持物化提示，例如PostgreSQL的 MATERIALIZED，也可以在CTE中强制物化，但流程较长时临时表仍然更直观。
另一个容易忽略的问题是日期边界。例如事实表中有跨月订单，销售日期与业务归属月份不一致。如果直接按销售日期平摊目标，边缘日期可能被归入错误月份。建议在事实表上额外保存业务月字段，统一用业务月关联目标月份，而不是仅仅依赖自然日拆分。最终计算完成率时，先用事实表关联临时表，再按业务月聚合：
SELECT
f.region,
f.business_month,
SUM(f.amount) AS actual_amount,
SUM(td.daily_target) AS target_amount
FROM fact_sales f
JOIN tmp_daily_target td
ON td.dt = f.sale_date
AND td.region = f.region
GROUP BY f.region, f.business_month;
这里 business_month 是事实表中预先保存的业务月份，fact_sales 只关联临时表中的日目标，不再直接关联粗粒度目标表。这样既能保持查询逻辑清晰，又能避免不同粒度直接关联带来的重复统计问题。
总体来看，利用临时表平摊关联粒度是一种非常实用的SQL建模手段。它把粒度对齐过程从主查询中剥离出来，先完成拆分、归一化、预计算，再用临时表与事实表关联。这种方式不仅让统计结果正确，也便于调试和复用，尤其适合目标管理、预算执行、库存分摊等跨粒度分析场景。