为何SQL中的Cartesian Product是生产环境中最常见的性能杀手？

Cartesian Product是漏写或写错连接条件时必然触发的确定性灾难，表现为EXPLAIN中type=ALL、rows呈乘积级膨胀、Extra含Using join buffer且Rows Removed by Filter:0等铁证。

Cartesian Product 不是“偶尔出错”，而是只要漏写或写坏连接条件，就必然触发的确定性灾难——它不报错、不中断、不警告，只默默把 1000 行 × 1000 行 = 100 万行塞进结果集，再一路拖垮内存、IO 和下游应用。

EXPLAIN 里看到 Nested Loop + Rows 突然暴涨，就是它在敲门

别等查询超时才怀疑，直接看执行计划里的真实信号：

• type 是 ALL（全表扫描）且没 key 字段，同时 rows 显示数值是两表行数相乘（比如 rows=982000，而表A有 982 行、表B有 1000 行）
• Extra 出现 Using join buffer (Block Nested Loop)，且 Rows Removed by Filter: 0
• PostgreSQL 的 EXPLAIN ANALYZE 里 Actual Rows 远大于任一输入表行数，且连接节点无 Join Filter
• SQL Server 执行计划 XML 中 PhysicalOp="Nested Loops" 但 Predicate 为空，EstimateRows 跳到百万/亿级

这些不是“可能有问题”，而是 Cartesian Product 已经落地的铁证。

FROM t1, t2 语法是新手雷区，LEFT JOIN ... ON 1=1 是老手陷阱

两种写法看着都合法，但效果一样危险：

• SELECT * FROM orders, customers; —— 旧式逗号语法，没 WHERE 就等于没约束
• SELECT * FROM orders o LEFT JOIN customers c ON 1=1; —— ON 里写恒真表达式，等价于没过滤
• SELECT * FROM orders o LEFT JOIN customers c ON o.id = c.order_id WHERE c.status = 'active'; —— WHERE 过滤右表字段，把 LEFT JOIN 实质降级为 INNER JOIN，若 c.status 为空值多，优化器可能放弃使用索引，退化成嵌套循环+全扫
• 拼错字段名：o.customer_id = c.cust_id（实际字段是 c.customer_id），数据库找不到列，该条件被忽略，只剩裸连接

加了 ON 条件 ≠ 问题消失，索引和统计信息才是最后一道防线

即使 ON 写对了，性能仍可能崩：

• 连接字段没索引：比如 orders.customer_id 有索引，但 customers.id 没索引，优化器无法走索引查找，只能对右表全扫，Nested Loop 代价爆炸
• 统计信息过期：ANALYZE 没跑过，优化器以为 customers 只有 10 行，实际有 10 万行，错误选择驱动表顺序，把大表当内层循环
• NULL 值干扰：左表 10 万行，右表 t1_id 字段允许 NULL 且占比 95%，即使有索引，匹配行也极少，但优化器按“平均选择率”估算，仍可能选错算法

真正安全的修复，必须三步闭环：ON 条件写对 → 连接字段双向建索引 → ANALYZE 更新统计信息 → 再看 EXPLAIN 是否消除高 rows 和 ALL 扫描。

最常被跳过的环节，是确认右表连接字段是否真的有索引——很多人只记得给外键加索引，却忘了外键指向的主键列本身也要可高效定位。