Explicit vs implicit SQL joins

Performance wise, they are exactly the same (at least in SQL Server).

PS: Be aware that the IMPLICIT OUTER JOIN syntax is deprecated since SQL Server 2005. (The IMPLICIT INNER JOIN syntax as used in the question is still supported)

Deprecation of "Old Style" JOIN Syntax: Only A Partial Thing

Personally I prefer the join syntax as its makes it clearer that the tables are joined and how they are joined. Try compare larger SQL queries where you selecting from 8 different tables and you have lots of filtering in the where. By using join syntax you separate out the parts where the tables are joined, to the part where you are filtering the rows.

On MySQL 5.1.51, both queries have identical execution plans:

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)

table1 has 166208 rows; table2 has about 1000 rows.

This is a very simple case; it doesn't by any means prove that the query optimizer wouldn't get confused and generate different plans in a more complicated case.