by Hayato Matsuura.

結合処理


あるSQLクエリがバーに入ったら、
そこには2つのテーブルがあった。
彼はそこに近づいて、こう尋ねた。
「君達、ジョインしてもいいかい?」

— 作者不詳

結合は、正規化されたモデルを、特定の目的を満たした非正規化されたモデルに変換する処理です。結合処理は、分散したデータの断片をまとめる処理 なので、ディスクシークのレイテンシに特に敏感です。適切なインデックスを作ることは、レスポンスタイムを短くするために、ここでも最適な解決策になります。 正しいインデックスがどんなものであるかは、そのクエリに対して、3つの一般的な結合アルゴリズムのどれが使われるかによって決まります。

協力してください

この記事が気に入ったら、私の書いた本「SQLパフォーマンス詳解」や私によるトレーニングもきっと気にいるはず。

ただ、どの結合アルゴリズムにも共通することがあります。それは、どの場合でも、同時に処理できるのは2つのテーブルまでということです。 つまり、3つ以上のテーブルを扱うSQLクエリは、まず最初に2つのテーブルを結合して中間テーブルを生成し、それからそれを次のテーブルと結合し…と いう処理を繰り返すのです。

中間結果のパイプライン化

中間結果を見れば結合のアルゴリズムがよく分かるのですが、だからと 言って、それを目に見える形にしなければならないということではありません。次に続く処理の前に、最初の結合の結果を保存しておく必要がある、という だけのことです。そのためデータベースは、メモリを節約するためパイプライン化を 行います。つまり、中間テーブルの各行はすぐにパイプライン化されて次の結合処理に渡され、これに よって中間結果の全体を保存する必要がないようにしているのです。

結合の順序は最終的な結果には関係ありませんが、パフォーマンスには影響を及ぼします。オプティマイザは全ての結合順序のパターンを評価して、 最適なものを選びます。これはつまり、複雑な文を最適化することは、やり方によってはパフォーマンス問題につながりかねないことを表します。 結合するテーブルが増えれば、評価しなければならない実行計画のパターンも増えます。数学的に言えば、これはn! (階乗)で増加して いきます。なお、バインドパラメータを使って いる時には、この問題の影響を受けません。

重要

文が複雑になればなるほど、バインドパラメータを使う重要性が増します。

バインドパラメータを使わないのは、毎回プログラムをコンパイルし直すようなものです。

目次

  1. 入れ子 ループ - ORMを使用した場合のN+1問題

  2. ハッシュ 結合 - 全く違うインデックス作成のやり方

  3. ソートマージ 結合 - まるでソートされた結果のジッパー

前へ次へ

著者について

Markus Winandの写真

Markus Winand氏は、開発者がSQLパフォーマンスを改善するお手伝いをしています。彼は、SQL Performance Explainedの 著者でもあり、出張トレーニングhttp://winand.at/での リモート講義も 行っています。

彼の本

カバー『SQLパフォーマンス詳解』

核心をわかりやすく 解説。

Markusから購入します
(送料無料+PDF)

Amazonで購入
(印刷版のみ)

“Use The Index, Luke!” by Markus Winand is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
法律上の通知 | 接触 | 無保証 | 商標 | Privacy | CC-BY-NC-ND 3.0 license