インデックス・アドバイザーの効果の確認 (V6R1)

カラム統計の自動取得と統計/索引アドバイザー」でも紹介したインデックス・アドバイザー(索引アドバイザー)ですが、
実際にアドバイスどおりにインデックスを作成すると効果があるのかどうか、を今回は見てみました。

自分で作ったSQL とかだとわざとらしいので、とりあえず「外部結合の使い方」に載っていたSQL を例にとってみてみました。

↑のSQL 実行後の Visual Explain が↓です。

インデックス・アドバイザーを見てみると、以下の 2つのインデックスがアドバイスされています。

インデックス・アドバイザーに従ってインデックスを作成し、実行してみました。
その実行後の Visual Explain が↓です。

最適化時間(Optimization Time)は増えていますが(75 → 151)、実行時間(Run Time)は大幅に減っている(288 → 52)のがわかりますね。
トータルでの実行時間(Total Time For All Runs)も減っています(289→53)。

最適化時間は最初の実行ただ一回のみにかかる時間です。最適化されたアクセス・プランはプラン・キャッシュというところにキャッシュされて再利用されますので、キャッシュされた後は実行時間のみがかかります。プラン・キャッシュのサイズの上限値がきちんと設定されていれば、IPL 以外にキャッシュ・アウトされることはありません。

キャッシュ後の実行は、この大幅に短縮された実行時間の方だけが実際の SQL の実行にかかる時間になるので、レスポンスタイムも速くなりますし、その分使用される CPU 時間も少なくなる、というわけです。総量としての CPU時間も短くなるので、CPU の空いている時間も増え、その間に他のSQL も実行できることになります。システムのキャパシティ計画にも余裕ができますね。何回も実行されるような処理であれば、さらにそれだけ効果が期待できます。

では、比較のために改めてインデックス作成前の Visual Explain に戻って見てみましょう。

アクセス・プランの見た目は、絵で見ればまったく同じです。。が、インデックス・スキャンのところのアイコンをクリックしてみましょう。
インデックスとしてはテーブルのプライマリー・キー制約が使用されていることがわかります。

インデックス・スキャンにかかった時間(Processing Time)は .194 ms になっています。

インデックス・アドバイザーに従ったインデックスを作成後の Visual Explain で同じところを見てみましょう。
同じ「インデックス・アクセス "index probe"」ですが、テーブルについているプライマリー・キー制約ではなく、まさしくアドバイスに従って作成されたインデックスが使用されています。

ときどき、「PF に UNIQUE が指定されたキーがついているのに、同じものをインデックス・アドバイザーからアドバイスされたのだが、意味あるのか?」といった話を聞くのですが、大抵のケースではこのように意味はあるんですね。(少なくとも、直接使用されなかった場合でも(後述するように)統計情報の提供元として有用であるケースがほとんどです)

これが実行時間が大幅に速くなった一因ですね。Processing Time が .194 から .025 に短くなっています。

ではもうひとつのインデックスはどうなっているの? というのは至極もっともな疑問です。
Visual Explain に現れないので、使われていないのか? というと、実はそんなことはないんですね。

ちゃんと統計情報の提供元として使用されています。これもインデックスの果たす重要な機能です。

この 2つの総合力で、この SQL は速くなっているわけです。

ぜひ、まずはインデックス・アドバイザーに従ってインデックスを作成してみることから始めてみてください。

また、Visual Explain を見て、使用されていないから無用だったのだ、と早合点もしないようにしてください。
通常、↑のように統計情報の正確な提供元として使用されています。直接 System i ナビゲーターSYSTABLEINDEXSTATなどを使用して確認してみてください。

一定期間様子を見た上で、「ストアド・プロシージャによるインデックス使用状況の調査 (V5R4 以降)」などの方法を使って、本当にそのインデックスが役に立っているかどうかを調べて、使われていないようなら削除する、といったサイクルを回していくのがよいのではないかと思います。

[Top Pageに戻る]

Ads by TOK2