JOIN 就是 INNER JOIN 的简写形式，SQL 标准中无独立语义，所有主流数据库均将其解析为内连接，执行结果、执行计划完全一致，且 JOIN 后必须带 ON 子句，否则语法错误。
JOIN 就是 INNER JOIN 的简写形式
SQL 标准里没有独立的 JOIN 语义，它只是 INNER JOIN 的语法糖。所有主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）在解析时都会把裸写的 JOIN 自动重写为 INNER JOIN，执行计划也完全一致。
常见错误现象：有人看到 SELECT * FROM a JOIN b ON a.id = b.id 能跑通，就以为 JOIN 是“默认连接”，再看到 LEFT JOIN 时误以为三者是并列关系 —— 实际上 LEFT JOIN 和 JOIN 并不处于同一抽象层级：JOIN 是内连接的缩写，LEFT JOIN 是另一类连接操作。
- 写
JOIN或INNER JOIN，结果行数、字段顺序、NULL 行分布都一模一样 - 执行计划中，两者显示的连接类型均为
InnerJoin（或类似标识），不会出现歧义 - 部分老项目用逗号语法
FROM a, b WHERE a.id = b.id，它逻辑等价，但已被 SQL-92 标准弃用，可读性差且易误写成笛卡尔积
ON 条件才是决定是否为内连接的关键
真正让查询变成“内连接”的，不是关键字本身，而是 ON 子句的存在和语义。只要写了 ON，无论前面是 JOIN 还是 INNER JOIN，数据库都会按内连接逻辑执行：只保留两边都匹配的行。
容易踩的坑：有人试图去掉 ON 写成 SELECT * FROM a JOIN b，这在多数数据库里会报错（如 MySQL 5.7+ 报 ERROR 1064），因为 JOIN 语法强制要求显式连接条件；而旧式逗号语法 FROM a, b 却能成功执行，但结果是笛卡尔积 —— 这正是混淆的根源。
-
JOIN后必须跟ON，否则语法错误（不是“默认内连接”，是“语法不完整”） -
CROSS JOIN才是明确表示笛卡尔积的合法写法，它不允许带ON - 哪怕
ON 1=1这种恒真条件，仍是内连接，只是效果等同于CROSS JOIN（但语义不同，优化器可能处理方式有差异）
LEFT JOIN 中的 JOIN 不能被替换成 INNER JOIN
这里有个关键陷阱：LEFT JOIN 里的 JOIN 不是独立关键字，而是整个连接类型的组成部分。你不能把 LEFT JOIN 拆成 “LEFT + JOIN”，然后认为这个 JOIN 会被解释为 INNER JOIN —— 它就是 LEFT JOIN，一个原子操作符。
典型误用场景：在已有 LEFT JOIN 的查询里，把 ON 条件挪到 WHERE 子句，比如把 ON a.id = b.id AND b.status = 'active' 改成 ON a.id = b.id WHERE b.status = 'active'，结果左表没匹配的行全被过滤掉，LEFT JOIN 形同虚设。
-
LEFT JOIN、RIGHT JOIN、FULL OUTER JOIN都是完整关键字，不可拆分 -
JOIN单独出现时，永远等价于INNER JOIN；出现在复合关键字中时，不参与语义解析 - 混用风格（如
FROM a LEFT JOIN b INNER JOIN c ON ...）时，优先级和括号逻辑容易出错，建议显式加括号或分步写 CTE
为什么设计成这样？兼容性和演进路径
SQL-89 标准只支持逗号连接和 WHERE 关联，SQL-92 引入了显式 JOIN 语法来提升可读性与可控性。JOIN 作为 INNER JOIN 的简写，是为了平滑过渡：老代码把逗号换成 JOIN 就能升级，无需重写逻辑。
性能影响几乎为零，但可维护性差别很大。团队协作中，统一用 INNER JOIN 而非 JOIN，能减少新人误解；而坚持用 JOIN 的人，往往更熟悉 SQL-92 之后的现代写法 —— 两种都没问题，关键是全项目保持一致。
- MySQL 8.0、PostgreSQL 15 等新版本对两种写法的优化完全相同，无任何执行开销差异
- 某些 ORM（如 Django ORM 生成的 SQL）默认输出
INNER JOIN，而手写脚本常用JOIN，混合存在时审查需多看一眼 - 最容易被忽略的是：当嵌套多个连接时，
JOIN的省略可能掩盖驱动表选择意图，影响索引使用判断
