"選択"を行う時のオプティマイザーの動きを見てみたいと思います。
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 の時間、必要なメモリー容量などがわかります。
小さいテーブルなので大したコストはかかりませんね。それでもやはり選択に使用されたカラムについて、索引の作成が推奨されています。
テーブル・スキャンのコストで十分、ということで、わざわざ一時索引などを作成することもなくテーブル・スキャンが選択されていることがわかります。
|
|