每个JOIN后必须写ON，否则MySQL 8.0+报错，旧版或ORM可能退化为笛卡尔积；右表过滤条件须放ON而非WHERE，否则LEFT JOIN失效；子查询作表用时仍需ON关联；多表连接需每对相邻表都有业务ON条件。
每个JOIN后面必须写ON，不写就是笛卡尔积
显式JOIN（如LEFT JOIN、INNER JOIN）不会自动猜字段关系。漏掉ON子句，MySQL 8.0+ 直接报ERROR 1064；旧版或某些ORM可能静默退化为CROSS JOIN，结果就是纯笛卡尔积。
-
SELECT * FROM orders LEFT JOIN customers;→ 错误，等效于CROSS JOIN -
SELECT * FROM orders LEFT JOIN customers ON orders.customer_id = customers.id;→ 正确 -
USING (customer_id)可以替代ON，但要求两表字段名完全一致、类型兼容，不是“省事借口”
LEFT JOIN的右表过滤条件必须放ON里，不能放WHERE
WHERE在连接完成后才执行，而ON控制连接过程本身。把右表过滤条件塞进WHERE，会把本该保留的左表空匹配行也干掉，实际效果等于INNER JOIN，还多跑一遍全量配对。
- 错误：
LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active'→ 所有无客户匹配或状态非 active 的订单全丢 - 正确：
LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active'→ 左表行数不变，只拉活跃客户 - 若业务要求“所有订单 + VIP用户信息”，
WHERE里绝不能出现c.level这类右表字段
子查询当表用时，照样要ON关联，且得控粒度
子查询出现在FROM或JOIN右侧，就变成一张临时表，和外层表之间仍需真实业务意义的ON条件。更危险的是：没聚合、没去重，就把明细原样摊开再连。
- 危险：
LEFT JOIN (SELECT order_id, SUM(amount) FROM payments GROUP BY order_id) b ON 1=1→ON 1=1等同于没限制 - 安全：
LEFT JOIN (SELECT order_id, SUM(amount) AS total FROM payments GROUP BY order_id) b ON a.id = b.order_id - 若子查询不含
order_id（比如只查统计值无主键引用），就不能直接JOIN，应改用标量子查询或EXISTS
三张及以上表连接，检查每对相邻表是否都有业务ON条件
不能只确保首尾两张表有关联，中间每一对都得有真实业务逻辑的ON。跳过中间实体强行连接，数据库只能暴力匹配，中间表形同虚设。
- 错误链路：
orders JOIN products ON orders.id = products.id→ 没这业务逻辑，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查看行数是否合理；若某步后行数突增数十倍，大概率断链了
实际出问题时，往往不是语法报错，而是结果行数突然翻几十倍、内存溢出、查询卡死——这些信号比错误提示更早出现。别依赖DISTINCT或COUNT(*)补救，它们不减少中间膨胀，只在最后徒劳去重或统计虚高数字。
