ON条件漏写关联字段会导致笛卡尔积，如两万行表JOIN返回亿级行；常见错误包括ON 1=1、字段未限定表别名、多表JOIN时关联错位、LEFT JOIN中WHERE误用等，需通过count对比、EXPLaiN验证和显式别名规避。
ON 条件漏写关联字段，直接触发全表交叉
sql 执行时没报错，但结果行数爆炸式增长——大概率是 ON 后面压根没写有效关联条件。比如两个各 1 万行的表做 INNER JOIN，结果返回 1 亿行，基本可以断定是 ON 后面只写了常量或恒真表达式。
常见错误写法：
-
ON 1=1（显式全连接） -
ON TRUE（postgresql 允许，效果同上） -
ON t1.id IS NOT NULL（没涉及右表，等价于无约束） - 忘记写右表字段，如
ON t1.user_id = user_id（此时user_id若在两表都存在，可能被隐式解析为左表，实际变成t1.user_id = t1.user_id）
这类写法不会报语法错误，但会让优化器放弃关联逻辑，退化为嵌套循环的全组合。
JOIN 多表时 ON 子句绑定错位，关联关系断裂
三张表连查时，第二个 JOIN 的 ON 条件如果错误地只关联了第一张表，就等于把第三张表和前两张的中间结果做笛卡尔积。
例如：
SELECT * FROM orders o JOIN users u ON o.user_id = u.id JOIN items i ON o.order_id = i.order_id 这里 i 只和 o 关联，但没约束 u 和 i 的关系。若一个订单含 10 个商品、对应 1 个用户，中间结果 o JOIN u 是 1 行，再和 i 做 ON o.order_id = i.order_id 没问题；但如果 items 表里有脏数据（比如 order_id 为空或重复），或者本应通过 users 过滤但漏了，就容易放大结果。
更危险的是写成：
JOIN items i ON u.id = i.user_id 而 items 表根本没有 user_id 字段——此时 mysql 可能静默忽略该条件（取决于 SQL mode），PostgreSQL 则直接报错。但一旦字段名碰巧存在又语义错配，就很难察觉。
ON 中混用 WHERE 逻辑，导致外连接行为异常
LEFT JOIN 时，把本该放在 WHERE 的过滤条件错误塞进 ON，会改变连接语义，有时表现为“看似左连接，实则变内连接”，有时却因条件失效引发意外膨胀。
典型陷阱：
-
LEFT JOIN logs l ON l.user_id = u.id AND l.status = 'success'
这条本身不会导致笛卡尔积，但如果logs表对每个user_id有多条status = 'success'记录，就会重复拉取用户行。 - 更隐蔽的是：
LEFT JOIN logs l ON l.user_id = u.id WHERE l.status = 'success'
看似合理，但WHERE会过滤掉所有l为NULL的行，让LEFT JOIN失效，等价于INNER JOIN。而如果开发者误以为还能保留用户，后续加其他JOIN就容易叠加失控。
关键区别：ON 决定“哪些右表行能匹配进来”；WHERE 是对最终结果集的筛选，发生在连接完成之后。
没有验证 JOIN 结果基数，靠肉眼判断风险极高
开发时习惯性加 LIMIT 10 查看数据，但无法暴露笛卡尔积问题——因为前 10 行可能恰好来自同一组匹配。
必须做的检查：
- 对每个
JOIN后的结果，用COUNT(*)和COUNT(DISTINCT left_key)对比，看是否远大于左表行数 - 在
ON条件中强制使用表别名限定字段，杜绝歧义（如一律写t1.a = t2.b，不写a = b） - 对多对多关联场景（如订单与商品），确认是否需要先聚合或加中间表约束，而不是硬连
- 开启执行计划查看（
EXPLAIN），关注rows估算值是否异常跳升，尤其注意type: ALL或Extra: using join buffer提示
笛卡尔积不是总会立刻崩掉数据库，而是悄无声息地让查询变慢、内存吃紧、下游应用拿到错乱数据——它最危险的地方，是看起来“还能跑”。