不能直接JOIN多个事实表，因其缺乏天然主外键关系，易引发笛卡尔积、重复计数或漏数据；应通过共享维度表（如dim_customer、dim_date）中转关联，确保粒度对齐与数据一致性。
为什么不能直接 JOIN 多个事实表
事实表之间通常没有天然的主外键关系，强行用业务字段（比如 order_id 和 payment_id）硬连，容易导致笛卡尔积、重复计数或漏数据。核心问题在于：事实表描述的是不同粒度、不同时效、不同上下文的业务过程，它们之间缺乏一致的“锚点”。维度表才是那个稳定的锚——比如 dim_date、dim_customer、dim_product，它们提供统一的、可复用的上下文标识。
怎么用维度表中转关联两个事实表
关键不是让事实表彼此拉手，而是让它们各自 JOIN 同一个维度表，再通过该维度的自然键（如 customer_sk、date_key）对齐。典型场景是查“某客户在某天的下单金额 + 支付金额”：
SELECT d.customer_name, d.region, f1.order_date_key, SUM(f1.order_amount) AS total_orders, SUM(f2.payment_amount) AS total_payments FROM fact_orders f1 JOIN dim_customer d ON f1.customer_sk = d.customer_sk JOIN fact_payments f2 ON d.customer_sk = f2.customer_sk AND f1.order_date_key = f2.payment_date_key GROUP BY d.customer_name, d.region, f1.order_date_key;
注意这里用了两次 dim_customer（一次接 fact_orders，一次接 fact_payments），并用 order_date_key 和 payment_date_key 对齐时间维度——这比直接 fact_orders JOIN fact_payments ON order_id = related_order_id 更可靠，尤其当支付可能分多笔、延迟或退款时。
哪些维度表适合当中转？选错会出什么问题
优先选择高覆盖、低变更、业务语义清晰的维度表。常用且安全的有：dim_customer、dim_date、dim_product。慎用或需额外校验的包括：
-
dim_store：如果订单和库存事实表的“门店”定义不一致（比如订单按收货地址，库存按仓管归属），JOIN 后数据会失真 -
dim_promotion：促销维度常有 SCD Type 2 变更，若没对齐生效时间窗口（start_date/end_date），容易把 A 促销的订单算进 B 促销的支付里 - 自建临时维度（如用
SELECT DISTINCT customer_id FROM ...）：缺少代理键和历史快照，无法支持缓慢变化或退化维度场景
性能和写法上容易踩的坑
维度表中转看似简单，但实际执行时容易慢或出错：
- 没加索引：确保所有 JOIN 字段（如
customer_sk、date_key）在事实表和维度表上都有 B-Tree 或位图索引 - 忽略空值：
LEFT JOIN维度表时，若事实表的customer_sk是 NULL，会导致整行丢失；应先用COALESCE(f1.customer_sk, -1)并在维度表补一条customer_sk = -1的未知记录 - 过度 JOIN：不需要的维度（比如查销量时 JOIN 了
dim_employee）会拖慢查询，也增加内存压力；只保留真正用于过滤或分组的维度 - 日期对齐陷阱：别默认用
order_date_key = payment_date_key；更合理的可能是payment_date_key >= order_date_key且限定payment_date_key <= order_date_key + 30（30天账期）
最常被忽略的一点：维度表的代理键（customer_sk）必须全局唯一且稳定，一旦 ETL 过程中生成逻辑出错（比如同客户不同天生成了不同 sk），中转就完全失效——这种错误不会报错，只会静默污染结果。
