不写ON条件、用OR做连接、误用CROSS JOIN会触发笛卡尔积，导致集群雪崩；安全JOIN须满足驱动表可过滤、关联字段有索引、连接条件为等值。
直接说结论：不写 ON 条件、用 或 OR 做连接、误用 CROSS JOIN，这三类写法在大数据量下基本等于主动触发集群雪崩。真正安全的 JOIN 必须满足「驱动表可过滤 + 关联字段有索引 + 连接条件是等值」三个硬条件。
哪些 SQL 写法会悄悄生成笛卡尔积
不是所有看起来像 JOIN 的语句都会出问题，但以下写法在 Spark SQL 和 Hive 中几乎必然触发全量交叉 —— 尤其当表数据量超过百万行时：
-
SELECT * FROM a JOIN b（完全没写ON）—— 物理计划里直接出现CartesianProduct -
ON a.id b.id（不等值连接）—— 优化器无法下推过滤，多数情况退化为广播+嵌套循环 -
ON a.id = b.id OR a.name = b.name（OR条件）—— 索引失效，且 Spark 2.x/3.x 默认不支持该条件下的 SortMergeJoin -
CROSS JOIN ... ON a.id = b.id（显式写CROSS JOIN却又加ON）—— 语义矛盾，部分版本会忽略ON直接算笛卡尔积
LEFT JOIN 大表时为什么更容易踩坑
LEFT JOIN 的执行逻辑决定了它比 INNER JOIN 更容易放大笛卡尔积风险：
- 左表必须全扫描，哪怕你只想要其中 1% 的数据，也要先读完全部再关联
- 如果右表没索引，每一条左表记录都要遍历右表全量匹配 —— 时间复杂度接近
O(n×m) - WHERE 条件写在 JOIN 后（如
LEFT JOIN b ON ... WHERE b.status = 'valid'）会导致右表 NULL 行被过滤，但左表已全扫完，浪费不可逆
正确做法是把右表过滤提前到子查询或 CTE：(SELECT * FROM b WHERE status = 'valid') b，让 JOIN 前就压降右表数据量。
如何快速判断当前 SQL 是否已触发笛卡尔积
别等任务跑失败，查执行计划是最准的：
- Spark UI 的 SQL tab 里看物理计划，出现
CartesianProduct节点就是实锤 - Hive/MySQL 中用
EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN EXTENDED，观察是否有rows预估暴涨（比如左表 10 万 × 右表 50 万 → 预估 50 亿行） - 运行后查
Spark UI → Stages → Shuffle Write Size / Input Rows，若某 stage 的Input Rows是左表行数的数十倍以上，基本已在局部笛卡尔积
特别注意：有些 SQL 看似写了 ON，但关联字段类型不一致（如 string vs bigint），也会导致隐式转换 + 索引失效 + 全表扫描，效果等同于没写 ON。
最常被忽略的一点：分区裁剪和谓词下推必须同时生效。即使你写了 WHERE dt = '2026-11-01'，但如果 JOIN 条件里用了函数（如 ON to_date(a.ts) = b.date），分区信息就传不到右表，右表仍可能扫全量分区 —— 笛卡尔积风险藏在细节里。
