为什么SQL笛卡尔积是生产环境最常见性能杀手
先说一个核心判断：笛卡尔积在生产环境里，从来不是什么“偶发事故”，只要漏写了连接条件，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”——只要踩一次，代价就是整个系统的可用性。理解它、识别它、预防它，才是每个数据库工程师的必修课。