DB2 LUWにおける実行計画の処理


DB2 LUWの実行計画の処理でも最も一般的なものについての、 簡単なリファレンスです。全てのリストはIBMの ドキュメントを参照してください。

インデックスとテーブルへのアクセス

IXSCAN

IXSCANは、Bツリーの走査に 加えて、一致するエントリを探すのに リーフノードチェーンをたどります。第1章, 「 SQLインデックスの内部構造も参照して下さい。.

いわゆるインデックスフィルタ述語("SARG"述語)は、 IXSCANの際にパフォーマンス問題を引き起こします。次の節で、 その問題の識別方法を説明しています。OracleでいうINDEX ... SCANと 同じ種類の処理です。

STARTSTOPがなければ、 フルインデックススキャンが行われている事にになります。

last_explained ビューでは、逆順のスキャンを括弧内に表示します (例、IXSCAN (REVERSE))。

FETCH

前段のインデックス検索で取得したRIDを使って、 テーブルから行を取り出します。第1章, 「 SQLインデックスの内部構造も参照してください。 Oracleで言うTABLE ACCESS BY INDEX ROWIDと 同じ処理です。

TBSCAN

フルテーブルスキャンとして知られる処理です。 テーブル全体つまり全行・全列をディスクに保存されている通りに 読みます。複数ブロックの読み出し処理により、フルテーブルスキャンの 速度は大幅に改善されはしますが、最も重い処理の1つである事に 変わりありません。IO処理も多いですが、フルテーブルスキャンでは 全てのテーブルの行の値をチェックしなければならないので、 かなりのCPU時間も消費します。「フルテーブルスキャン」も参照して下さい。

RIDSCN

この処理は、インデックスマージの際に使われます。 ソート後にデータページを先読みするのに使われる事の方が多いかもしれません。

結合処理

通常、結合処理で同時に処理できるのは 2テーブルまでです。1つのクエリにそれ以上の結合対象のテーブルがある場合、 まず2つのテーブルを結合し、それからその中間結果を次のテーブルと 結合するというように、順番に処理されます。結合の話をする場合には、 「テーブル」という言葉は「中間結果」の事を指す場合もあるのです。

NLJOIN

片方のテーブルから結果を取り出し、その結果をもう1つの テーブルの各行に対して問い合わせて、2つのテーブルを結合します。 「入れ子ループ」も参照して下さい。

HSJOIN

ハッシュ結合では、結合の片方から候補となるレコードを ハッシュテーブルにロードし、それを結合のもう片方の各行と 突き合わせます。「ハッシュ結合」も参照して下さい。

MSJOIN

マージ結合は、並べ替えられた2つのリストをジッパーのように マージします。結合の両辺は事前にソートしておく必要があります。 「ソートマージ」も参照して下さい。

ZZJOIN

スタースキーマを使ったデータウェアハウス向けの、 マルチテーブル結合(2つ以上のテーブルの結合)です。

ソートとグルーピング

SORT

order by句に従って、結果をソートします。 この処理は、中間結果(パイプライン化されていないもの)を マテリアライズするために、非常に多くのメモリを必要とします。 また、MSJOINGRPBYと言った 処理のためにデータを必要な順序に並べ替える場合にも使われます。 さらにSORTは、distinctがある時に 重複した行を削除するのにも使われます。 「インデックスを使ったorder by」も参照して下さい。

last_explainedビューでは、 一意なソートが行われているか括弧内に表示します (例、SORT (UNIQUE))。最初のN件のみのソートは、 TOP-Nのラベルが付きます(例、because of fetch first ... rows only).

UNIQUE

ソート済みのセットから重複行を排除します。 SORT処理なしに必要な順序でデータが得られる場合で distinctがある時の処理で使われます (例えばIXSCANで必要な順序で結果が得られる時)。 SORT処理が行われる時には、 SORTが重複排除を行います。

GRPBY

group by列の結果をまとめます。 この処理は、ソートやgroup-byアルゴリズム、 あるいはハッシュベースアのプローチ(v10.1以降)を使って実行されます。 「インデックスを使ったgroup by」も参照してください。

last_explainedビューでは、 このまとめる処理を括弧内に表示します (例、GRPBY (HASH COMPLETE))。

最初のN件のみを選択するクエリ

DB2 LUWには、fetch first ... rows onlyの様な 最初のN件のみを選択するクエリに直接対応する実行計画の処理は ありません。しかし、SORT処理が行われた場合に、last_explainedビューでは、 最初のN件のみの最適化が行われている事を括弧内に表示します (例、SORT (TOP-N))

SORT処理が必要ない時には、最初のN件のみを選択するクエリに ついての表示は特に出ません。しかし、述語情報が無いのにコスト値や行数見積が 急に減っている時は、最初のN件のみを選択する仕組みがはたらいていると 分かるでしょう。

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