笛卡尔积必然发生于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 写对了，性能也扛不住。
