笛卡尔积必然发生于on缺失、恒真、歧义或失效时，中间结果集迅速失控；需检查on是否存在及语法正确、字段可匹配性、类型一致性，并用exists替代低效left join。

笛卡尔积不是“偶尔出错”，而是只要 ON 条件缺失、恒真、歧义或失效，它就一定发生——而且中间结果集会立刻失控，查几万行表就能返回上亿行。

检查ON子句是否真的存在且语法正确

最常见的是漏写 ON，或混用老式逗号语法却忘了补 WHERE 关联。比如：

SELECT * FROM orders, customers;

这等价于 CROSS JOIN，没有任何约束。还有更隐蔽的写法：

• LEFT JOIN order_items i ON o.order_id = order_id：右边没写表别名，PostgreSQL 会默认解析成 o.order_id = o.order_id，恒真
• JOIN users u ON u.id = id：若两表都有 id 字段，MySQL 可能按上下文猜，但结果不可控
• 大小写拼错，如把 customer_id 写成 customerId（Linux 环境下表/字段名区分大小写）

验证ON两侧字段是否真实可匹配

即使语法没错，字段值本身也可能让条件“形同虚设”。需手动确认：

• 执行 EXPLAIN，看 type 列：若为 ALL 或 index，且 rows 值远超单表行数，说明没走索引，连接条件大概率未生效
• 查重复：SELECT order_id, COUNT(*) FROM orders GROUP BY order_id HAVING COUNT(*) > 1
• 查 NULL：SELECT COUNT(*) FROM orders WHERE customer_id IS NULL；若用 INNER JOIN，这些行直接丢弃；若用 LEFT JOIN 后再 WHERE 过滤右表字段，就会退化为全量扫描+空匹配
• 确认外键是否真实存在：SELECT constraint_name FROM information_schema.key_column_usage WHERE table_name = 'order_items' AND column_name = 'order_id'

警惕类型不匹配与隐式转换

字段类型不一致是静默杀手——值看起来一样，但数据库无法用索引，只能全表扫描再逐行比对：

• orders.customer_id 是 BIGINT，customers.id 是 VARCHAR → 每次比较都触发隐式转换
• ON UPPER(a.code) = UPPER(b.code) → 函数导致索引失效，优化器可能被迫选哈希连接，中间结果暴涨
• 修复方式只有统一类型（改表结构），或显式 CAST（不推荐长期使用）

用EXISTS替代低效的LEFT JOIN + WHERE筛选

当目标只是判断“主表某条记录在从表是否存在”，LEFT JOIN ... WHERE b.id IS NOT NULL 是危险写法：

• 先生成全部左连接结果（含大量 NULL 行），再过滤，中间结果集极易爆炸
• 应改用 EXISTS：SELECT o.* FROM orders o WHERE EXISTS (SELECT 1 FROM order_items i WHERE i.order_id = o.order_id)
• EXISTS 是半连接，找到第一个匹配即停，不物化中间结果，也不受右表重复值影响

真正难处理的，是既要判断存在性、又要取明细字段的场景——这时候必须确保右表有 (order_id) 或 (order_id, item_id) 的有效索引，否则哪怕 ON 写对了，性能也扛不住。