INNER JOINまたはINを使用したINNER SELECTのどちらが速いのだろうかと思っていましたか?
select t1.* from test1 t1
inner join test2 t2 on t1.id = t2.id
where t2.id = 'blah'
また
select t1.* from test1 t1
where t1.id IN (select t2.id from test2 t2 where t2.id = 'blah')
が重要であると仮定するid
と、これらのクエリは同じことを意味し、適切な DBMS はまったく同じ方法でそれらを実行します。残念ながら、このSQL Fiddleの [View Execution Plan] リンクを展開するとわかるように、MySQL はそうではありません。どちらが高速になるかは、おそらくテーブルのサイズによって異なりますTABLE1
。行数が非常に少ない場合は、IN が高速になる可能性がありますが、他のすべての場合は JOIN が高速になる可能性があります。
これは、MySQL のクエリ オプティマイザの特性です。Oracle、PostgreSQL、またはMS SQL Serverがこのような単純な同等のクエリを異なる方法で実行するのを見たことがありません。
推測する必要がある場合、INNER JOIN
は よりも効率的である可能性IN (SELECT ...)
がありますが、クエリごとに異なる場合があります。
EXPLAIN
キーワードはあなたの親友の 1 つです。EXPLAIN
完全なクエリの前に入力SELECT
すると、MySQL はクエリの実行方法に関する基本的な情報を提供します。ファイルの並べ替えを使用している場所、作成したインデックスを使用している場所 (およびそれらを無視している場所)、および要求を満たすためにおそらく調べる必要がある行の数がわかります。
他のすべてが等しい場合は、INNER JOIN
より予測可能であり、新しい開発者が理解しやすいため、mostly を使用します。しかし、もちろん、IN (SELECT ...)
フォームに実際の利点がある場合は、それを使用してください!
問い合わせているRDBSの実行計画を確認する必要がありますが、そのinner join
方が速いか、少なくとも同じであると思います。私が間違っていたら、誰かが私を訂正してくれるかもしれません。
ネストされた select は、内部クエリ全体を実行する可能性が最も高く、 から可能な値のハッシュ テーブルを作成しますtest2
。そのクエリが 100 万行を返す場合、何があってもそのデータをメモリにロードするコストが発生します。
内部結合では、test1
行が 2 つしかない場合、それらの各行test2
の値に対して2 つのインデックス スキャンを実行するだけで、100 万行をメモリにロードする必要はありません。id
各テーブルに統計があるため、最新のデータベース システムで最初のシナリオを最適化できる可能性もありますが、最良の場合、内部結合は同じになります。
ほとんどの場合、JOIN はサブクエリよりもはるかに高速ですが、サブクエリは JOIN よりも読みやすいです。
RDBMS は JOIN に対して実行計画を作成するため、どのデータをロードして処理する必要があるかを予測できます。これは間違いなく時間を節約します。一方、サブクエリの場合、すべてのクエリを実行し、すべてのデータをロードして処理を行います。