SQL执行计划中出现“Cartesian Product”意味着两表连接缺失有效条件（如ON或WHERE关联谓词），导致优化器退化为全组合扫描，生成m×n行结果，极易引发性能崩溃。
SQL执行计划里出现“Cartesian Product”意味着什么
这通常不是优化器主动选择的策略，而是因为缺少有效的 JOIN 条件（比如 ON 或 WHERE 中的关联谓词），导致两张表之间没有约束性连接逻辑。数据库只能退化为全组合扫描——N 行 × M 行，数据量稍大就直接拖垮查询。
怎么快速定位是不是漏写了JOIN条件
重点检查以下几类常见疏漏：
- 使用了
FROM t1, t2旧式语法但忘了在WHERE里写t1.id = t2.t1_id -
LEFT JOIN t2 ON ...的ON子句为空、或只写了常量（如ON 1=1） - 多个
JOIN嵌套时，最内层的ON被错放到外层WHERE，导致逻辑失效（尤其在有LEFT JOIN时，WHERE过滤右表字段会隐式转成INNER JOIN） - 拼写错误：比如
t1.user_id = t2.usr_id（少了个e），字段不存在，优化器可能忽略该条件
EXPLAIN 输出里怎么确认是笛卡尔积
不同数据库提示略有差异，但共性信号明显：
- PostgreSQL：
Nested Loop节点下子节点的Rows Removed by Filter: 0，且Actual Rows接近table1_rows × table2_rows - MySQL：
EXPLAIN的type列为ALL且rows显示乘积级数量；或Extra出现Using join buffer (Block Nested Loop)+ 高行数 - SQL Server：执行计划 XML 中
EstimateRows突然跳到亿级，且PhysicalOp是Nested Loops无Predicate
别只看“Cartesian Product”字样——有些版本（如较新 PostgreSQL）压根不打这个词，得看行数膨胀和连接类型是否失配。
修复后务必验证的两个细节
加完 ON 条件不等于问题消失：
- 检查字段是否都建了索引：如果
t2.t1_id没索引，即使有ON，也可能回退到嵌套循环+全表扫描，性能依旧差 - 确认
NULL处理逻辑：例如LEFT JOIN ... ON t1.id = t2.t1_id，若t2.t1_id允许NULL且数量多，实际匹配行仍可能远少于预期，需结合ANALYZE查看真实统计分布
笛卡尔积往往暴露的是数据建模断层，而不是单条 SQL 的笔误。看到它，优先翻一翻外键定义和ER图里这两张表本该怎么连。
