MySQL中INNER JOIN是否比WHERE子句隐式连接更优化？

核心结论 #

只要两种写法语义完全等价，执行性能没有任何区别，不存在隐式连接先生成全量笛卡尔积、再走WHERE过滤导致性能更差的情况。

常见认知误区的来源 #

很多开发者对两种写法的性能担忧，本质是混淆了SQL语法书写顺序和数据库实际执行逻辑：

• 从语法书写形式上看，隐式连接是把表通过逗号列在FROM子句中，把表之间的匹配规则写在WHERE子句里，看起来像是先算出所有表的笛卡尔积，再用WHERE条件过滤掉不匹配的行
• 但从实际执行流程看，MySQL优化器（5.0之后的所有版本，包括现在主流使用的5.7、8.x系列）会在执行前做统一的语义解析：只要识别到WHERE子句里的等值条件是不同表之间的关联匹配规则，就会将其等价转换为内连接的执行逻辑，根本不会先生成全量笛卡尔积再逐行过滤。

要验证这一点非常简单：对下面两段语义完全一致的SQL分别执行EXPLAIN，会得到完全相同的扫描行数、连接顺序、索引使用情况，没有可感知的性能差异：

-- 隐式逗号连接写法
SELECT sample
FROM table1, table2
WHERE table1.key = table2.key;

-- 显式INNER JOIN写法
SELECT sample
FROM table1 INNER JOIN table2 
  ON table1.key = table2.key;

两者真正的差异体现在可维护性上 #

虽然性能层面没有区别，但行业内依然更推荐使用显式INNER JOIN写法，核心原因和性能无关，是实际开发的经验总结：

• 隐式逗号连接的写法容错率极低，很容易漏写表之间的连接条件。一旦漏写关联规则，数据库是真的会生成全量笛卡尔积（比如两个各10万行的表漏写条件，就会生成100亿行的中间结果，直接拖垮数据库实例）；再加上所有条件都堆在WHERE子句里，排查问题时很容易漏找关联逻辑。
• 显式INNER JOIN的写法职责边界清晰：ON子句专门写表与表之间的匹配关联规则，WHERE子句专门写关联完成后需要过滤的结果行规则。写代码时不容易漏写关联条件，后续维护的人读SQL时也能一眼看懂表之间的关系，不用在一堆过滤条件里翻找关联逻辑。

额外提醒 #

如果真的遇到隐式连接生成笛卡尔积、性能很差的情况，不要把锅甩给语法本身——本质问题是漏写了连接条件。哪怕全用显式INNER JOIN，只要两个表的匹配条件没写对，一样会生成笛卡尔积造成性能雪崩。
早期非常老的MySQL 3.x版本，优化器能力不足，确实存在识别不出WHERE里的连接条件、真的先生成笛卡尔积再过滤的问题，但这个问题早在二十年前的版本迭代中就被修复了，完全没必要拿上古版本的问题当现在的开发规范依据。

内容的提问来源于stack exchange，提问作者tootiefairy