CROSS JOIN行数等于各表行数乘积，执行前即确定，但实际生成可能远超预期；需通过子查询/CTE提前收敛、构造虚拟维度、控制驱动表顺序等方式确保输入轻量可控。
为什么CROSS JOIN行数不是“看起来多少就是多少”
CROSS JOIN的最终行数 = 所有参与表的行数乘积，这个数字在SQL执行前就已确定，但实际生成过程可能远超预期。比如dim_month（12行）和dim_province（34行）组合是408行，没问题；但若误把orders（日均50万行）和product_catalog（10万款）放进去，中间结果就是500亿行——数据库往往卡在构建阶段，连EXPLAIN都跑不出来。
- 别信“加WHERE能救”，多数引擎（尤其是Hive、MySQL）先算全量笛卡尔积再过滤，中间数据早爆了
-
EXPLAIN里看到rows字段为“N/A”或极大值，基本说明优化器已放弃估算，直接准备硬扛 - PostgreSQL中
work_mem设得太小，会强制落盘到temp_files，IO飙升；SQL Server则容易触发WRITELOG等待
用子查询/CTE提前收敛驱动表行数
真正可控的做法，是把“大表”变成“小结果集”，再参与CROSS JOIN。关键不是过滤后加LIMIT，而是让CROSS JOIN的输入本身足够轻。
- 对业务表必须先做
SELECT DISTINCT或按关键维度聚合：比如(SELECT DISTINCT province FROM sales WHERE dt >= '2026-07-01') AS provinces - 用
VALUES或generate_series()构造虚拟维度，完全绕开业务表：PostgreSQL可写(SELECT * FROM generate_series(1, 50)) AS seq，MySQL 8.0+用(VALUES (1),(2),...,(50)) AS t(n) - Hive里避免直接引用分区大表，改用
WITH filtered AS (SELECT ... FROM src WHERE ds='2026-07-01') SELECT * FROM filtered CROSS JOIN dim
三张及以上表组合时，乘积爆炸比你想象得快
两表组合还能估算，三表开始就容易失守。100 × 50 × 30 = 15万行尚可；但1000 × 1000 × 100 = 1亿行，已逼近多数OLTP库单次查询安全阈值。
- 优先检查是否真需要全量组合：如果只是补“零值”，用
LEFT JOIN+ 实际存在组合做驱动更稳 - 真要多维组合，拆成两步：先
CROSS JOIN前两张表存临时表，再和第三张表JOIN，避免内存一次性吃紧 - 业务侧硬编码过滤条件比SQL层动态计算更可靠，比如“只允许华东/华北省份与TOP100产品线组合”，直接写进
WHERE
别忽略驱动表顺序和物理大小差异
CROSS JOIN虽无ON条件，但执行时仍有“左表驱动右表”的物理行为。左表每行都要扫描右表全量，所以左表越小，整体IO压力越低。
- 把枚举类小表（如
blood_types仅4行）放左边，业务维度表（如class_list可能上千行）放右边 - MySQL中若右表无主键或索引，
CROSS JOIN可能退化为嵌套循环全表扫描，速度骤降 - 某些引擎（如Spark SQL）会对CROSS JOIN自动广播小表，但前提是它能准确识别“小”——靠
ANALYZE TABLE更新统计信息，别依赖默认估算
控制规模的核心不在语法层面，而在于让每个参与CROSS JOIN的输入都是确定、轻量、可预期的。一旦任一端变成真实业务大表或未过滤的分区，就等于把油门焊死在底线上。
