执行计划出现cartesian product提示，说明两张表无有效关联条件，数据库被迫全量组合扫描；on缺失时优化器不猜测连接逻辑，直接执行笛卡尔积，mysql 8.0+报错error 1064，5.7等旧版本则静默转cross join导致性能灾难。
执行计划里出现 CARTESIAN PRODUCT 或类似提示（比如 Cartesian join、cross join、Using join buffer 配合超高行数），基本可以断定：两张表之间没有有效关联条件，数据库被迫做全量组合扫描。
为什么ON条件缺失会导致笛卡尔积
数据库优化器不会“猜”你怎么连表。当你写 FROM orders, customers 或 JOIN customers 却没跟 ON 子句，它只能按最保守方式处理——把左表每行和右表每行配一遍。1万行 × 10万行 = 10亿行中间结果，内存扛不住，磁盘IO爆掉，查询直接卡死。
- MySQL 8.0+ 在严格模式下会直接报错
ERROR 1064: syntax error near JOIN，不让你执行 - MySQL 5.7 或旧版本可能静默转成
CROSS JOIN，表面成功，实则灾难 - PostgreSQL 和 Spark SQL 不一定打
CARTESIAN PRODUCT字样，得看rows是否突增、type是否为Seq Scan+Nested Loop无Filter - Hive 默认禁止笛卡尔积，报错
SemanticException Cartesian products are disabled for safety reasons
常见漏写或写错 ON 条件的场景
不是所有语法错误都会报红，很多是“合法但无效”，查不出错，结果却爆炸。
-
FROM a, b WHERE a.id = b.user_id：旧式逗号语法，WHERE 里写了条件，但优化器仍可能先算笛卡尔再过滤，尤其数据量大时 -
LEFT JOIN b ON 1=1或ON a.id IS NOT NULL：这类常量条件等价于没约束 -
ON a.cust_id = b.customer_id但 b 表实际字段叫customerid（少下划线）或customer_ID（大小写敏感）：字段不存在 → 全部转为NULL→NULL = NULL判定为 false → 关联失效 -
LEFT JOIN b ON a.id = b.a_id WHERE b.status = 'active'：WHERE 过滤右表字段，会把左连接退化成内连接，且若b.status索引失效，仍可能触发嵌套循环全扫
怎么快速确认是不是笛卡尔积
别只盯着“Cartesian”这个词——有些引擎压根不显示它。重点看三处：
-
EXPLAIN输出中rows列数值是否接近两表行数乘积（比如table_a有 5000 行，table_b有 2000 行，rows显示 9982312） -
type是ALL（全表扫描）且Extra出现Using join buffer (Block Nested Loop) - Spark SQL 报错
Detected cartesian product for INNER join between logical plans，说明逻辑计划阶段已识别出风险，未等到运行时
加了 ON 就万事大吉？未必
补上 ON a.id = b.a_id 只解决了一半问题。如果 b.a_id 没索引，优化器大概率还是选 ALL 扫描 b 表，性能照样崩。
- 检查关联字段是否都有索引：
SHOW INDEX FROM b看a_id是否在Key_name列里 - 确认字段类型一致：比如
a.id是BIGINT，b.a_id是VARCHAR，隐式转换会让索引失效 - 留意 NULL 值影响：
LEFT JOIN中若右表关联字段大量为NULL，虽不膨胀行数，但匹配率低，实际效果可能不如预期 - 笛卡尔积常是建模问题的外显症状——翻翻 ER 图，这两张表本该通过哪个外键连？字段命名是否统一？
真正麻烦的不是语法错，而是“看起来对、跑起来慢、结果还错”。看到 CARTESIAN PRODUCT，第一反应不该是改 SQL，而是查外键定义、看统计信息、确认数据分布。
