CROSS JOIN不能直接当多维数据集用，它仅生成笛卡尔积，无分组聚合或层级语义；构建维度矩阵需先用CROSS JOIN生成组合骨架，再通过LEFT JOIN关联事实表并补空值。
直接说结论：CROSS JOIN 不是为“多维数据集”设计的，它只做笛卡尔积，没有分组、聚合或层级语义；真要构建维度矩阵（比如时间×地区×产品组合），得先用 CROSS JOIN 生成基础组合，再靠 LEFT JOIN 或子查询补事实数据，否则结果全是空壳。
为什么 CROSS JOIN 不能直接当多维数据集用
CROSS JOIN 的行为极其简单：把左表每一行和右表每一行配对，不判空、不过滤、不按任何键对齐。它不理解“维度”概念，也不关心某地区某月有没有销售记录——哪怕某个 (region, month) 组合在事实表里根本不存在，它照样出现在结果里。
- 常见错误现象：
SELECT * FROM dim_date CROSS JOIN dim_region CROSS JOIN dim_product返回 10 万行，但查SUM(sales)时全为NULL，因为没连事实表 - 使用场景：仅适合生成“所有可能组合”的骨架，比如预设报表模板、补全缺失维度值、构造测试数据
- 性能影响：3 个维度表各 100 行，结果就是 100×100×100 = 100 万行；表稍大就爆炸
怎么用 CROSS JOIN + LEFT JOIN 补事实数据
真正有用的维度矩阵，必须把组合结果和事实表对齐。核心逻辑是：先叉乘出完整空间，再用 LEFT JOIN 把事实数据“挂”上去，保留空组合（即 NULL 销售额）。
- 关键点：
LEFT JOIN的 ON 条件必须覆盖所有参与叉乘的维度字段，比如ON m.date_id = d.date_id AND m.region_id = r.region_id AND m.product_id = p.product_id - 别漏掉
COALESCE：事实字段（如amount）会是NULL，用COALESCE(m.amount, 0)转成 0 更符合业务预期 - 注意顺序：
CROSS JOIN部分必须放在FROM最左侧，LEFT JOIN事实表紧随其后，否则语法错或逻辑错
SELECT d.year_month, r.region_name, p.product_code, COALESCE(m.sales, 0) AS sales FROM dim_date d CROSS JOIN dim_region r CROSS JOIN dim_product p LEFT JOIN fact_sales m ON m.date_id = d.date_id AND m.region_id = r.region_id AND m.product_id = p.product_id;
CROSS JOIN 和隐式逗号语法的区别在哪
老写法 FROM t1, t2 看似等价，但实际风险高得多：它和 WHERE 条件耦合太紧，容易漏写关联条件导致意外笛卡尔积；而显式 CROSS JOIN 是独立语法结构，意图清晰，SQL 解析器也更容易做执行计划优化。
- 兼容性：所有主流数据库（PostgreSQL、SQL Server、MySQL 8.0+、Oracle）都支持
CROSS JOIN；MySQL 5.7 及更早版本对逗号语法更宽容，但行为不稳定 - 可读性陷阱：写
FROM a, b WHERE a.id = b.a_id时，如果手抖删了WHERE，整个查询就崩成笛卡尔积且无提示 - 参数差异：无参数可调，但部分数据库（如 Snowflake）允许在
CROSS JOIN后加/*+ ENABLE_JOIN_ORDER */提示来干预连接顺序
真正难的不是写出 CROSS JOIN，而是判断哪些维度该叉乘、哪些该用 INNER JOIN 过滤、哪些组合必须保留空值——这取决于你的分析口径，而不是 SQL 语法本身。
