あるSQLクエリがバーに入ったら、 そこには2つのテーブルがあった。 彼はそこに近づいて、こう尋ねた。 「君達、ジョインしてもいいかい？」— 作者不詳
結合は、正規化されたモデルを、特定の目的を満たした非正規化されたモデルに変換する処理です。結合処理は、分散したデータの断片をまとめる処理 なので、ディスクシークのレイテンシに特に敏感です。適切なインデックスを作ることは、レスポンスタイムを短くするために、ここでも最適な解決策になります。 正しいインデックスがどんなものであるかは、そのクエリに対して、3つの一般的な結合アルゴリズムのどれが使われるかによって決まります。
協力してください
この記事が気に入ったら、私の書いた本「SQLパフォーマンス詳解」や私によるトレーニングもきっと気にいるはず。
ただ、どの結合アルゴリズムにも共通することがあります。それは、どの場合でも、同時に処理できるのは2つのテーブルまでということです。 つまり、3つ以上のテーブルを扱うSQLクエリは、まず最初に2つのテーブルを結合して中間テーブルを生成し、それからそれを次のテーブルと結合し…と いう処理を繰り返すのです。
結合の順序は最終的な結果には関係ありませんが、パフォーマンスには影響を及ぼします。オプティマイザは全ての結合順序のパターンを評価して、 最適なものを選びます。これはつまり、複雑な文を最適化することは、やり方によってはパフォーマンス問題につながりかねないことを表します。 結合するテーブルが増えれば、評価しなければならない実行計画のパターンも増えます。数学的に言えば、これはn! (階乗)で増加して いきます。なお、バインドパラメータを使って いる時には、この問題の影響を受けません。
