単純な選択の場合のオプティマイザーの動き (DB2/400)

"選択"を行う時のオプティマイザーの動きを見てみたいと思います。

WHERE 句を指定した SQL を実行し、Visual Explain で生成されたアクセス・プランを見てみます。
実行した SQL は SELECT * FROM QIWS/QCUSTCDT WHERE STATE = 'TX' です。

一番最初に実行される「テーブルのスキャン」 のノードですが、実はより詳細にどんな処理を行っているかを見ることができます。
+ 記号をダブルクリックで展開することにより↓のようになります。

データベースエンジンの部品である"ノード"を組み合わせてアクセス・プランを作る DB2/400 のオプティマイザー独特の世界が垣間見えますね。まさしくオブジェクト指向のデータベース・エンジンです。

左から右、下から上に実行されるので、まず左下の"COLUMN"というノードを選択してみてください。
その"COLUMN"というノード/オブジェクトと対応する"属性"が右側のペインに表示されます。

"SQL"という属性を見ると、WHERE で指定されている STATE というカラムを比較対象に選んでいることがわかります。

"HOST VARIABLE"というノードですが、これはその名のとおりホスト変数を指しています。
↑の "COLUMN" ノードと"EQUAL TO"ノードで結合していることがわかります。

どういう部品をどういうトポロジーで結合するか = どういう処理をどう組み合わせるか、を表しています。
右ペインに表示されるホスト変数の値は 'MN' になっていますが、これは前回これと同じ SQL が 'MN' という値で実行された(アクセス・プラン作成時、ということです。つまりこれは再利用されている、ということでもありますね)ためにそうなっているだけです。あくまで形式を見るようにしてください。この値は、実際に後で適切な値に置き換えられます。

"COLUMN" ノードと "HOST VARIABLE" ノードとの結合、つまり、カラムと固定値の比較条件は "Equality" つまり "=" ですね。

"FINAL SELECT" のノードの内容です。

「ホスト変数値」に、今回の SQL 文の比較値である 'TX' が入っているのが確認できますね。

「テーブルのスキャン」のノードに戻ってみましょう。

展開された SQL 文を見ることができます。
結果として表示されている STATE の値はわざわざテーブルから持ってきているわけではないんですね。

その他、この選択にかかる CPU の時間、I/O の時間、必要なメモリー容量などがわかります。
小さいテーブルなので大したコストはかかりませんね。それでもやはり選択に使用されたカラムについて、索引の作成が推奨されています。

テーブル・スキャンのコストで十分、ということで、わざわざ一時索引などを作成することもなくテーブル・スキャンが選択されていることがわかります。

[Top Pageに戻る]

Ads by TOK2