状況によって異なりますが、サブクエリを使用してクエリを改善する場合がありました。
私が知っている要因は次のとおりです。
- サブクエリが比較のために外部クエリのフィールドを使用するかどうか（相関 かどうか）
- 外部クエリとサブクエリの関係がインデックスでカバーされている場合
- 結合に使用可能なインデックスがなく、サブクエリが相関しておらず、小さな結果を返す場合は、使用する方が速い可能性があります
- また、order byを使用するクエリを、それを使用しないクエリに変換し、それを単純なサブクエリとソートに変換してmysqlのパフォーマンスを向上させる状況に遭遇しました
とにかく、さまざまなバリアントをテストすることは常に良いことであり（SQL_NO_CACHEを使用してください）、相関クエリを結合に変換することは良い習慣です。
私はそれを非常に有用な実践と呼ぶことさえします。
相関クエリが最初に頭に浮かぶのは、主に集合演算ではなく、主に手続き演算であり、リレーショナルデータベースを扱う場合は、集合を完全に採用することが非常に役立つ可能性があります。データモデルとその変換に関する視点。
編集：手続き型とリレーショナル型
集合演算と手続きの観点から考えると、一部の集合代数式では同等になります。たとえば、和集合での選択は、選択の和集合と同等です。 2つの手順に違いはありません。
ただし、結合のすべての要素に選択基準を適用してから選択を適用するなど、2つの手順を比較すると、2つは明らかに異なる手順である可能性があります。非常に異なるプロパティがあります（たとえば、CPU、I / O、メモリの使用率）。
リレーショナルデータベースの背後にある考え方は、結果を取得する方法（手順）を説明するのではなく、必要なものだけを説明しようとすることと、データベース管理システムが要求を満たすための最適なパス（手順）を決定することです。これが、SQLが第4世代言語（4GL） と呼ばれる理由です。 。
これを行うのに役立つトリックの1つは、タプルには固有の順序がない（セット要素は順序付けされていない）ことを思い出させることです。もう1つは、関係代数が非常に包括的であり、要求（要件）をSQLに直接変換できることを認識しています（モデルは問題空間をうまく表しています。言い換えれば、テーブルと関係の名前に付けられた意味が正しく行われている場合、言い換えれば、データベースがうまく設計されている場合です。
したがって、どのように考える必要はなく、何を考える必要があります。
あなたの場合、それは相関クエリよりも優先されただけなので、私はあなたに新しいことを何も言っていないかもしれませんが、あなたはその点を強調したので、コメントしました。
クエリをあるフォームから別のフォームに変換するすべてのルールに完全に慣れている場合（ルール 分散性など）相関サブクエリを好まない（すべてのフォームが等しいと見なされる）
（注：上記では、データベース設計にとって重要な理論的背景について説明しています。実際には、上記の概念は逸脱しています。クエリの同等の書き換えがすべて高速で実行されるとは限りません。クラスター化された主キーにより、テーブルはディスク上で順序を継承します。逸脱は単なる逸脱です。同等のクエリがすべて高速に実行されるわけではないという事実は、実際のDBMSの欠陥であり、その背後にある概念ではありません）