星型模型中维表JOIN的关键在于结果准确性和性能稳定性：ON与WHERE必须严格分离，外键字段类型须完全一致并显式建索引，多维JOIN应按过滤性排序且及时更新统计信息。
星型模型里写维表 JOIN，核心不是语法对不对，而是结果准不准、性能扛不扛得住——很多慢查询和空值丢失，都是因为没搞清 ON 和 WHERE 的分工，或者外键字段类型悄悄不一致。
LEFT JOIN 的 ON 和 WHERE 必须严格分离
这是最容易出错的地方：把本该在 ON 里的维度过滤条件，误写进 WHERE，结果“所有用户”变成“有订单的用户”，语义直接崩掉。
-
ON只管“怎么连”：比如fact_sales.time_key = dim_date.date_key，或带维度限定的关联逻辑（如ON d.id = f.product_key AND d.is_current = 1） -
WHERE管“连完留哪些”：比如WHERE dim_date.year = 2024，这时它作用于已 JOIN 完的整张宽表，会把左表中没匹配到year = 2024维度行的记录整个筛掉 - 典型错误示例：
LEFT JOIN dim_product p ON f.product_key = p.id WHERE p.category = 'Electronics'→ 实际等效于INNER JOIN，0 单用户、停售商品全消失
JOIN 字段类型必须完全一致，不能靠隐式转换
事实表的 store_key 是 BIGINT，维度表的 id 就不能是 INT 或 VARCHAR。一旦类型不匹配，MySQL 会做隐式转换，索引失效；PostgreSQL 可能拒绝使用 Hash Join，退化成全表扫描。
- 检查方式：用
DESCRIBE table_name或\d table_name（PG）确认两边字段类型、长度、是否允许 NULL - 修复建议：统一用
BIGINT作外键/主键类型，避免用字符串存 ID（如'store_001'） - 特别注意时间字段：
fact_sales.sale_date是DATE，就别拿dim_date.full_date（DATETIME）去连，哪怕值一样，类型不同也会拖慢 JOIN
多维 JOIN 顺序不影响结果，但影响执行计划稳定性
SQL 标准规定 INNER JOIN 顺序可交换，但优化器不是总能选对驱动表——尤其当某张维度表刚加载完新数据、统计信息还没更新时，可能把百万行的 dim_customer 当驱动表去扫十亿行的 fact_sales。
- 优先让最小、过滤性最强的维度表靠前：比如加了
WHERE dim_time.quarter = '2024-Q2'，就把dim_time放第一个JOIN - 避免在 CTE 或 VIEW 里嵌套多层 JOIN 后再加提示：像
/*+ HASH_JOIN(f, d) */在 PostgreSQL 中常被忽略，不如直接ANALYZE dim_time更新统计信息来得稳 - 不要依赖
STRAIGHT_JOIN（MySQL）或LEADING（Oracle）硬控顺序，除非你反复验证过执行计划且确认优化器持续误判
事实表外键字段必须显式建索引，别只靠主键索引
维度表主键自带索引，没问题；但事实表上的外键列（如 time_key、product_key）默认无索引——它们是 JOIN 和 WHERE 的高频入口，不建索引，每次关联都是全表扫描。
- 复合索引优先考虑高频组合：比如常查“某类商品在某月销量”，就建
(product_key, time_key)而非两个单列索引 - 避免冗余索引：如果已有
(time_key, store_key)，就别单独再建time_key索引 - 定期更新统计信息：大批量导入后立刻执行
UPDATE STATISTICS（SQL Server）、ANALYZE（PG）或ANALYZE TABLE（MySQL），否则优化器以为维度表只有 10 行，选错执行路径
真正卡住星型查询的，往往不是 JOIN 写法本身，而是外键字段没索引、类型不一致、或者把维度过滤逻辑错塞进 WHERE —— 这些问题不会报错，但会让结果变少、变慢、甚至随数据增长突然恶化。动手前先看 EXPLAIN，比背一百条规则都管用。
