漏写ON条件会直接导致笛卡尔积，三表JOIN中任意一对缺失ON即等价于CROSS JOIN，行数呈乘积级爆炸；MySQL常静默执行而非报错，EXPLAIN中rows异常飙升是典型征兆，需逐个验证每对JOIN的ON是否有效且字段归属正确。
会直接产生笛卡尔积，结果行数爆炸，轻则查不出数据、重则拖垮数据库。
漏写ON条件 = 无约束连接
三表JOIN时，每一对表之间都必须有明确的ON条件。漏掉任意一个（比如A JOIN B ON ...写了，但B JOIN C ON ...没写），数据库就会把缺失关联的那两张表当作CROSS JOIN处理。
- 常见错误写法：
FROM orders o JOIN users u ON o.user_id = u.id JOIN items i（结尾没写ON） - 实际效果等价于：
orders × users × items，行数 =orders行数 × users行数 × items行数 - 哪怕只漏一个字段（如写成
ON o.item_id = i.id AND i.status，少了个= 'on_sale'），也可能因语法不完整被优化器忽略或恒真化
报错 vs 静默出错：哪个更危险？
MySQL 8.0+ 在严格模式下可能报Unknown column或Incorrect usage of JOIN and ON；但多数情况它会“尽力执行”——用隐式条件补全，结果就是静默的笛卡尔积。
- 静默出错更难排查：SQL能跑通、返回大量数据、业务逻辑看似“有结果”，但统计值完全失真
- EXPLAIN 看
rows列会明显异常：比如单表rows=1000，连接后rows=1000000，大概率就是漏了ON - 监控上表现为CPU/IO飙升、慢日志里出现“full join”提示（即使你没写
CROSS JOIN）
LEFT JOIN后漏写ON，左表数据反而保不住
很多人以为LEFT JOIN“天然保左表”，其实前提是所有JOIN都带有效ON。一旦中间某次LEFT JOIN漏写ON，不仅右表失控，左表也会被连带污染。
- 例如：
users u LEFT JOIN orders o ON u.id = o.user_id LEFT JOIN order_items i（漏ON）→u × i先发生，再和o关联，u的每一行都会跟i所有行配对 - 结果中会出现大量重复
u记录，且o字段大部分为NULL，根本不是“每个用户一行”的预期 - 这种写法在复杂查询里极难肉眼识别，必须逐个检查
JOIN ... ON是否成对出现
怎么快速验证三表JOIN是否漏条件？
别靠经验猜，用三步现场验证：
- 把每个
JOIN单独拆出来跑一遍两表关联，确认ON能走索引、返回行数合理 - 在最终SQL开头加
SELECT COUNT(*)，对比各单表COUNT和预估连接后行数（比如用户1万、订单10万、商品1千，三表合理连接应在10万量级，而非100亿） - 在WHERE里临时加
AND 1=0，看执行计划是否仍扫描全部中间表——如果是，说明某次JOIN没生效，大概率漏了ON
最麻烦的不是漏写，而是漏得“看起来像写了”：比如ON a.id = b.id AND c.status = 'valid'，这里c根本不在前两个表里，条件无效却无报错。
