在性能方面，它们是完全相同的(至少在SQL Server中)，但要注意，它们不支持这种连接语法，而且SQL server2005不支持开箱即用的连接语法。

我认为您想到的是已弃用的*=和=*操作符vs。“外连接”。

我刚刚测试了给出的两种格式，它们在SQL Server 2008数据库上正常工作。在我的案例中，他们得到了相同的执行计划，但我不能肯定地说这总是正确的。

第二种语法具有不必要的交叉连接的可能性:您可以向FROM部分添加表而不对应WHERE子句。这被认为是有害的。

正如Leigh Caldwell所述，查询优化器可以根据功能上类似于相同SQL语句的内容生成不同的查询计划。欲进一步阅读，请参阅以下两篇博客文章:-

一篇来自Oracle优化团队的帖子

另一篇来自“结构化数据”博客的文章

我希望你会觉得这很有趣。

在性能方面，它们是完全相同的(至少在SQL Server中)。

PS:请注意，自SQL Server 2005以来，隐式OUTER JOIN语法已弃用。(仍然支持问题中使用的隐式INNER JOIN语法)

“旧样式”JOIN语法的弃用:只是部分内容

根据我的经验，使用带有where子句的交叉连接语法通常会导致执行计划受到破坏，特别是在使用Microsoft SQL产品时。例如，SQL Server试图估计表行数的方法非常可怕。使用内部连接语法可以在一定程度上控制查询的执行方式。因此，从实用的角度来看，鉴于当前数据库技术的返祖性质，您必须使用内部连接。

在MySQL 5.1.51中，两个查询有相同的执行计划:

mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)

mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)

表1有166208行;表2大约有1000行。

这是一个非常简单的例子;这并不能证明查询优化器在更复杂的情况下不会感到困惑并生成不同的计划。