明示的な内部結合と暗黙的な内部結合に効率の違いはありますか? 例えば:
SELECT * FROM
table a INNER JOIN table b
ON a.id = b.id;
対。
SELECT a.*, b.*
FROM table a, table b
WHERE a.id = b.id;
パフォーマンスに関しては、それらはまったく同じです (少なくとも SQL Server では)。
PS: IMPLICIT OUTER JOIN
SQL Server 2005 以降、この構文は非推奨になっていることに注意してください (IMPLICIT INNER JOIN
質問で使用されている構文は引き続きサポートされています) 。
個人的には、テーブルが結合されていることと、テーブルがどのように結合されているかが明確になるため、結合構文が好きです。8つの異なるテーブルから選択するより大きなSQLクエリを比較してみてください。ここでは、多くのフィルタリングが行われます。結合構文を使用することにより、テーブルが結合されている部分を、行をフィルタリングしている部分に分離します。
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)
table1
166208 行あります。table2
約1000行あります。
これは非常に単純なケースです。より複雑なケースでクエリ オプティマイザーが混乱して別のプランを生成しないことを証明するものではありません。
2 番目の構文には、望ましくない交差結合の可能性があります。対応する WHERE 句がなくても FROM 部分にテーブルを追加できます。これは有害であると考えられています。
あなたが与えた最初の答えは、ANSI結合構文として知られているものを使用しています.もう1つは有効で、どのリレーショナルデータベースでも機能します.
ANSI結合構文を使用する必要があるというgromに同意します。彼らが言ったように、主な理由は明確にすることです。多数の述語を含む where 句を使用するのではなく、その一部はテーブルを結合し、他のものは ANSI 結合構文で返される行を制限するのではなく、どの条件がテーブルの結合に使用され、どの条件がテーブルの結合を制限するために使用されているかを盲目的に明確にします。結果。
@lomaxx:明確にするために、上記の構文は両方ともSQL Serv 2005でサポートされていると確信しています。ただし、以下の構文はサポートされていません。
select a.*, b.*
from table a, table b
where a.id *= b.id;
具体的には、外部結合(* =)はサポートされていません。
パフォーマンスに関しては、これらは(少なくともSQL Serverでは)まったく同じですが、この結合構文は廃止されており、そのままではsqlserver2005ではサポートされていないことに注意してください。
非推奨の*=および=*演算子と「外部結合」について考えていると思います。
与えられた2つの形式をテストしたところ、SQLServer2008データベースで正しく機能します。私の場合、それらは同一の実行計画を生み出しましたが、これが常に真実であるとは自信を持って言えませんでした。
一部のデータベース(特にOracle)では、結合の順序がクエリのパフォーマンスに大きな違いをもたらす可能性があります(3つ以上のテーブルがある場合)。あるアプリケーションでは、文字通り2桁の違いがある場合がありました。内部結合構文を使用すると、これを制御できます-適切なヒント構文を使用する場合。
使用しているデータベースを指定していませんが、確率は、SQLServerまたはMySQLが実際に違いがない場所を示唆しています。
Leigh Caldwell が述べているように、クエリ オプティマイザーは、機能的には同じ SQL ステートメントのように見えるものに基づいて、異なるクエリ プランを作成できます。これについてさらに読むには、次の 2 つのブログ投稿をご覧ください。
Oracle Optimizer チームからの 1 つの投稿
これが興味深いと思うことを願っています。
パフォーマンスに関しては、違いはありません。明示的な結合構文は、from 句でテーブル間の関係を明確に定義し、where 句を乱雑にしないため、私にはすっきりしているように見えます。
私の経験では、cross-join-with-a-where-clause 構文を使用すると、特に Microsoft SQL 製品を使用している場合は、脳が損傷した実行計画が生成されることがよくあります。たとえば、SQL Server がテーブルの行数を推定しようとする方法は、非常に恐ろしいものです。内部結合構文を使用すると、クエリの実行方法をある程度制御できます。したがって、実用的な観点からは、現在のデータベース テクノロジの先祖返り的な性質を考えると、内部結合を使用する必要があります。