先说一个核心判断：笛卡尔积在生产环境里，从来不是什么“偶发事故”，只要漏写了连接条件，SQL连一声招呼都不打，直接给你把数据翻倍翻上亿倍。它不报错、不中断、不警告，只默默把 1000 行 × 1000 行 = 100 万行塞进结果集，再一路拖垮内存、IO 和下游应用。

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

• 如果你看到 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 跳到百万/亿级 —— 这时候再犹豫就等于在给性能挖坑。

这些不是“可能有问题”，而是笛卡尔积已经落地的铁证。

两种写法，一个结果：从新手雷区到老手陷阱

写法上，老问题和新花样都值得认真聊一聊。

旧式逗号语法：最经典的翻车现场

比如 SELECT * FROM orders, customers; —— 没加 WHERE 条件就相当于没约束，两表直接做笛卡尔积。这在新手代码中极其常见，一查一个准。

LEFT JOIN + 恒真表达式：老手也会踩的坑

SELECT * FROM orders o LEFT JOIN customers c ON 1=1; 这种写法，ON 里写恒真表达式，等价于没过滤。老手可能想的是“快速测试”，结果直接炸掉。

WHERE 条件反噬：看似合理实则危险

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 条件写对了，性能仍然可能崩。这里面有几个容易被忽视的环节：

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

真正的安全修复，必须三步闭环：先确认 ON 条件写对，再给连接字段双向建索引，然后执行 ANALYZE 更新统计信息。最后回头看 EXPLAIN，确认 rows 是否回归正常、ALL 扫描是否消失。

最常被跳过的环节，是确认右表连接字段是否真的有索引。很多人只记得给外键加索引，却忘了外键指向的主键列本身也要可高效定位。这一个小小的遗漏，足以让整条查询在线上拖到崩溃。

说句大白话：笛卡尔积就是SQL性能的“死xue”——只要踩一次，代价就是整个系统的可用性。理解它、识别它、预防它，才是每个数据库工程师的必修课。