結合クエリまたはサブクエリ

Question

サブクエリの代わりに結合を使用する場合、またはそれらが同じである場合、開発者向けの経験則があります。

Answer 1

RDBMSに依存します。両方のクエリの実行プランを比較する必要があります。

Oracle 10と11の経験では、実行計画は常に同じです。

Answer 2

最初の原則は、<！> quot;クエリを正確に記述する<！> quot;です。 2番目の原則は、<！> quot;クエリを単純かつ明確に<！> quotと記述することです。 （通常選択する場所です）。 3番目は<！> quot;クエリを記述して、効率的に処理する<！> quot;です。

優れたクエリプロセッサを備えたdbmsの場合、同等のクエリデザインでは、クエリプランは同じ（または少なくとも同等に効率的）になります。

MySQLを初めて使用したときの最大の不満は、オプティマイザーを予測するためにどれだけ意識する必要があるかでした。 Oracle、SQL Server、Informix、および他のdbms製品での長い経験の後、私はそのような問題に自分自身が関与することをほとんど期待していませんでした。現在、MySQLの新しいバージョンの方が優れていますが、他のバージョンよりも頻繁に注意を払う必要があることに変わりはありません。

Answer 3

パフォーマンスに関しては、ほとんどの最新のDBエンジンで違いはありません。

Answer 4

サブクエリの問題は、キーなしでサブ結果セットを持つのを終了する可能性があるため、それらを結合するとより高価になることです。

可能であれば、WHEREの代わりに、常にJOINクエリを作成し、ON句でフィルター処理を試みます（ただし、最新のエンジンはこのために最適化されているため、同じである必要があります）。

Answer 5

理論的には、すべてのサブクエリを結合クエリに変更できます。

Answer 6

多くのものと同様に、それは依存します。 -サブクエリの複雑さ -クエリ内でサブクエリが実行される頻度

できる限り、サブクエリを避けるようにします。特に、大きな結果セットが予期される場合、サブクエリは決して使用されません-サブクエリが結果セットの各項目に対して実行される場合。

気をつけて、 アレックス

Answer 7

今のところ、パフォーマンスへの影響を無視しましょう（<！> quot;時期尚早の最適化がすべての悪の根源であることを認識している場合はそうすべきです<！> quot;）。

より明確で保守しやすいものを選択します。

Answer 8

SQL Serverでは、通常、相関サブクエリのパフォーマンスは結合よりも劣ります。また、パフォーマンスにとってはしばしば、派生テーブルへの結合よりもパフォーマンスが良くなります。複数回実行する必要のあるサブクエリを書くことはほとんどありません。これは、相関サブクエリが基本的にクエリをカーソルに変え、一度に1行ずつ実行することが多いためです。データベースでは、通常、セットベースの方法で物事を行う方が良いです