每个JOIN后必须显式写ON子句，否则将导致笛卡尔积或报错；USING要求字段名完全一致；子查询作表时仍需ON关联；多表连接须保证每对相邻表都有业务逻辑的ON条件；WHERE不能替代ON减少中间结果集；连接字段类型须一致，否则索引失效。
漏掉任何一个 ON 条件，就等于给数据库开了张无限组合的空白支票。
每个 JOIN 后必须跟有效的 ON 子句
显式 JOIN 语法（如 LEFT JOIN、INNER JOIN）不会默认帮你关联字段；不写 ON，MySQL 或 PostgreSQL 会直接报错（严格模式下），而某些旧版或宽松配置可能退化为隐式 CROSS JOIN，结果就是笛卡尔积。
- ❌ 错误：
SELECT * FROM orders LEFT JOIN customers;（缺ON） - ✅ 正确：
SELECT * FROM orders LEFT JOIN customers ON orders.customer_id = customers.id; - ⚠️ 注意：
USING也能替代ON，但要求字段名完全一致且在两表中都存在，例如USING (customer_id)；它不是“省略条件”的借口
嵌套子查询里也得有明确关联逻辑
子查询一旦出现在 FROM 或 JOIN 右侧，它就变成一张“临时表”，和外层表之间依然需要 ON 或等效约束。常见陷阱是以为子查询内部已过滤，外部就不用再连——其实不然。
- ❌ 危险写法：
SELECT a.*, b.total FROM orders a LEFT JOIN (SELECT order_id, SUM(amount) AS total FROM payments GROUP BY order_id) b ON 1=1;（ON 1=1等同于没限制） - ✅ 安全写法：
... LEFT JOIN (...) b ON a.id = b.order_id; - ? 若子查询不含
order_id（比如只查统计值无主键引用），那就不能直接JOIN，应改用标量子查询或EXISTS
多表连接时检查“桥接链”是否断裂
三张及以上表连接时，不能只确保“首尾两张表”有关系，中间每一对相邻表都得有真实业务意义的 ON 条件。跳过中间实体强行连接，数据库只能暴力匹配。
- 场景：查
orders → order_items → products，但写了orders JOIN products ON orders.id = products.id（无此业务逻辑） - 后果：
orders和products行数相乘，中间的order_items形同虚设 - ✅ 正确链路：
orders JOIN order_items ON orders.id = order_items.order_id JOIN products ON order_items.product_id = products.id - ? 验证方法：对每个
JOIN后的中间结果加LIMIT 5查看行数是否合理；若某步后行数突增数十倍，大概率断链了
别让 WHERE 承担本该由 ON 完成的职责
WHERE 是在连接完成之后才执行的筛选，它无法减少连接过程中的中间膨胀。靠它“补救”缺失的 ON 条件，只是把爆炸延迟到后期，性能更差。
- ❌ 低效且危险：
FROM orders, customers WHERE customers.city = 'Shanghai'（漏掉orders.customer_id = customers.id） - ✅ 清晰分离：
FROM orders JOIN customers ON orders.customer_id = customers.id WHERE customers.city = 'Shanghai' - ? 特别注意：在
LEFT JOIN中，若把右表字段的非空判断写进WHERE（如WHERE b.status IS NOT NULL），实际效果等同于INNER JOIN，这不是笛卡尔积，但会悄悄破坏左连接语义
最常被忽略的一点是：连接字段类型不一致也会让 ON 失效——比如一边是 BIGINT，另一边是 VARCHAR，数据库被迫做隐式转换，索引失效，最终退化为全表扫描匹配，结果和没写 ON 几乎一样。
