ON条件决定连接匹配，WHERE条件过滤最终结果；LEFT JOIN中右表过滤必须放ON，否则退化为INNER JOIN；INNER JOIN中二者结果通常一致但性能不同。
SQL 中的 JOIN 不是“合并连接”，而是基于逻辑关联的行级匹配操作；它不依赖表结构是否“合并”，而取决于你能否写出有效的连接条件和明确的语义意图。
ON 条件必须存在且有意义
没有 ON 子句的 JOIN（比如只写 FROM a JOIN b）在标准 SQL 中非法；MySQL 虽允许省略，但会退化为 CROSS JOIN，产生笛卡尔积——数据量稍大就爆炸。实际中几乎总是错误。
- 连接列类型最好一致，比如
INT对INT、VARCHAR对VARCHAR；隐式转换可能引发索引失效或意外匹配 - 避免在
ON中对连接字段使用函数，如ON UPPER(a.name) = UPPER(b.name)，会导致无法走索引 - 多字段连接要写全，比如
ON a.id = b.a_id AND a.version = b.a_version，漏一个就可能扩大匹配范围
LEFT JOIN 里 ON 和 WHERE 的位置决定结果是否“丢失左表”
这是最容易翻车的地方：把本该写在 ON 中的右表过滤条件错放到 WHERE，会让 LEFT JOIN 变成事实上的 INNER JOIN。
- 正确：筛选右表某类记录但保留左表全部 → 条件写在
ON，例如LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 错误：条件写在
WHERE o.status = 'paid'→ 所有o.status IS NULL的用户行被过滤掉，左表“不全”了 - 验证方法：先执行不带
WHERE的查询，观察右表列为NULL的行是否存在；再加条件，看这些行是否消失
JOIN 多张表时，顺序和括号影响可读性与执行逻辑
SQL 标准不强制规定多表 JOIN 的结合顺序，但数据库优化器通常按 FROM 后出现顺序处理，尤其在使用 LEFT JOIN 时，顺序直接决定“主表”是谁。
-
SELECT * FROM a LEFT JOIN b ON ... LEFT JOIN c ON ...：以a为主表，b和c都是它的左外连接目标 - 如果想让
c基于b的结果再连接，应显式用括号：FROM a LEFT JOIN (b JOIN c ON ...) ON ...或拆成子查询 - 别名必须唯一，否则
column reference 'id' is ambiguous这类错误会立刻报出
真正难的不是语法，而是厘清“我要保留谁、过滤谁、匹配依据是什么”；一旦业务语义模糊，JOIN 写出来大概率查不到想要的数据，或者查到一堆 NULL 却不知道为什么。
