必须用CROSS JOIN生成全量组合时才使用，如dim_month（12行）与dim_province（34行）构建“月份×省份”骨架；小维度表间显式交叉是安全做法，而大业务表直接CROSS JOIN会导致笛卡尔积爆炸。
什么时候该用CROSS JOIN，而不是写一堆WHERE条件
CROSS JOIN不是“能不用就不用”的操作符，而是专门用来生成全量组合的——比如你手头有dim_month（12行）和dim_province（34行），要生成所有“月份 × 省份”组合，就必须靠它。这时候用LEFT JOIN ... ON 1=1或逗号语法虽然等效，但语义模糊，容易被后续维护者误判为疏漏。真正该回避的，是拿两个业务大表（比如user_logs和product_catalog）直接CROSS JOIN，这种组合数动辄上亿，Hive或MySQL都会卡死。
小表 + 显式构造维度，是唯一安全的用法
所谓“小表”，指行数稳定、可预期、且通常 WITH子句显式构造，而非直接JOIN业务表：
- 用
UNION ALL拼出固定枚举值（如血型A/B/C/D、状态active/inactive/pending） - 对真实维度表提前
SELECT DISTINCT去重并LIMIT 1000兜底 - 绝对不把
orders、events这类日志表当作任一端参与CROSS JOIN
示例中blood_types和class_list都是可控的小结果集，哪怕班级扩到100个、血型加到8种，组合也才800行，完全在安全边界内。
别信“加WHERE就能救”，执行计划往往先算笛卡尔积再过滤
下面这种写法看着像在控制规模，实际很危险：
SELECT * FROM orders CROSS JOIN product_catalog WHERE orders.order_date = '2024-01-01';
多数SQL引擎（尤其是Hive）会先生成orders × product_catalog全量笛卡尔积，再走WHERE过滤——中间数据可能超TB级。正确做法是：先用子查询/CTE把orders按日期筛好，再和product_catalog做CROSS JOIN：
WITH filtered_orders AS ( SELECT * FROM orders WHERE order_date = '2024-01-01' ) SELECT * FROM filtered_orders CROSS JOIN product_catalog;
这样filtered_orders若只有1万单，product_catalog有5000款商品，最终结果5000万行，虽大但可控；而原写法可能先爆出百亿行中间结果。
组合爆炸时，优先考虑替代方案而非硬扛
当维度数 ≥ 3（比如月份 × 省份 × 产品线 × 渠道），即使每维都小，乘积也可能失控。这时应放弃CROSS JOIN，改用：
-
INSERT OVERWRITE分步生成：先两两组合，存中间表，再逐步JOIN - 用
SELECT DISTINCT+LEFT JOIN反向补空：只取实际存在的组合，再用COALESCE填充缺失指标 - 业务侧预定义组合规则（如“仅华东+华北省份需与全部产品线组合”），用
WHERE硬编码过滤条件
真正难的不是写出CROSS JOIN，而是判断“这个组合是否真的需要全量生成”。很多所谓“必须补零”的报表，其实只需要展示有数据的维度交叉，强行全量反而掩盖了数据稀疏的真实问题。
