450

明示的な内部結合と暗黙的な内部結合に効率の違いはありますか? 例えば:

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;
4

12 に答える 12

154

パフォーマンスに関しては、それらはまったく同じです (少なくとも SQL Server では)。

PS: IMPLICIT OUTER JOINSQL Server 2005 以降、この構文は非推奨になっていることに注意してください (IMPLICIT INNER JOIN質問で使用されている構文は引き続きサポートされています) 。

「古いスタイル」の JOIN 構文の非推奨: 部分的なもののみ

于 2008-09-04T22:56:56.413 に答える
146

個人的には、テーブルが結合されていることと、テーブルがどのように結合されているかが明確になるため、結合構文が好きです。8つの異なるテーブルから選択するより大きなSQLクエリを比較してみてください。ここでは、多くのフィルタリングが行われます。結合構文を使用することにより、テーブルが結合されている部分を、行をフィルタリングしている部分に分離します。

于 2008-09-04T23:23:25.460 に答える
64

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)

table1166208 行あります。table2約1000行あります。

これは非常に単純なケースです。より複雑なケースでクエリ オプティマイザーが混乱して別のプランを生成しないことを証明するものではありません。

于 2012-04-25T01:43:26.570 に答える
42

2 番目の構文には、望ましくない交差結合の可能性があります。対応する WHERE 句がなくても FROM 部分にテーブルを追加できます。これは有害であると考えられています。

于 2008-11-25T14:13:22.747 に答える
17

あなたが与えた最初の答えは、ANSI結合構文として知られているものを使用しています.もう1つは有効で、どのリレーショナルデータベースでも機能します.

ANSI結合構文を使用する必要があるというgromに同意します。彼らが言ったように、主な理由は明確にすることです。多数の述語を含む where 句を使用するのではなく、その一部はテーブルを結合し、他のものは ANSI 結合構文で返される行を制限するのではなく、どの条件がテーブルの結合に使用され、どの条件がテーブルの結合を制限するために使用されているかを盲目的に明確にします。結果。

于 2008-09-07T09:55:30.260 に答える
7

@lomaxx:明確にするために、上記の構文は両方ともSQL Serv 2005でサポートされていると確信しています。ただし、以下の構文はサポートされていません。

select a.*, b.*  
from table a, table b  
where a.id *= b.id;

具体的には、外部結合(* =)はサポートされていません。

于 2008-09-04T23:39:08.933 に答える
6

パフォーマンスに関しては、これらは(少なくともSQL Serverでは)まったく同じですが、この結合構文は廃止されており、そのままではsqlserver2005ではサポートされていないことに注意してください。

非推奨の*=および=*演算子と「外部結合」について考えていると思います。

与えられた2つの形式をテストしたところ、SQLServer2008データベースで正しく機能します。私の場合、それらは同一の実行計画を生み出しましたが、これが常に真実であるとは自信を持って言えませんでした。

于 2008-09-04T23:33:25.967 に答える
3

一部のデータベース(特にOracle)では、結合の順序がクエリのパフォーマンスに大きな違いをもたらす可能性があります(3つ以上のテーブルがある場合)。あるアプリケーションでは、文字通り2桁の違いがある場合がありました。内部結合構文を使用すると、これを制御できます-適切なヒント構文を使用する場合。

使用しているデータベースを指定していませんが、確率は、SQLServerまたはMySQLが実際に違いがない場所を示唆しています。

于 2008-09-04T23:38:08.997 に答える
2

Leigh Caldwell が述べているように、クエリ オプティマイザーは、機能的には同じ SQL ステートメントのように見えるものに基づいて、異なるクエリ プランを作成できます。これについてさらに読むには、次の 2 つのブログ投稿をご覧ください。

Oracle Optimizer チームからの 1 つの投稿

「構造化データ」ブログからの別の投稿

これが興味深いと思うことを願っています。

于 2008-09-17T17:44:01.733 に答える
1

パフォーマンスに関しては、違いはありません。明示的な結合構文は、from 句でテーブル間の関係を明確に定義し、where 句を乱雑にしないため、私にはすっきりしているように見えます。

于 2011-11-30T18:30:32.577 に答える
-1

私の経験では、cross-join-with-a-where-clause 構文を使用すると、特に Microsoft SQL 製品を使用している場合は、脳が損傷した実行計画が生成されることがよくあります。たとえば、SQL Server がテーブルの行数を推定しようとする方法は、非常に恐ろしいものです。内部結合構文を使用すると、クエリの実行方法をある程度制御できます。したがって、実用的な観点からは、現在のデータベース テクノロジの先祖返り的な性質を考えると、内部結合を使用する必要があります。

于 2015-08-13T18:09:17.997 に答える