多くの場合、コストベース・アプローチを使用することで、オプティマイザは最適な実行計画を選択してくれますが、時として好ましくない実行計画を選択してしまうこともあります。
例えば、バインド変数を使用したSQLでは、SQLが解析(hard parse)された時点で指定されていたバインド変数の値を基に実行計画が決定されます(bind peek機能)。共有SQL領域に該当のSQLが残っている間は、同一のSQLはバインド変数の値にかかわらず、上記で決定された実行計画を使用するため、異なる値をセットしたSQLでは適切でない実行計画となってしまう可能性があります。
このような場合、SQLにヒントを指定することで、全表スキャンや索引スキャンといったアクセス方法や結合方法/順序などを、オプティマイザに明示的に指示できます。
チューニングに使用することが多い代表的なヒントとして、以下のようなものがあります。
| ヒントの種類 | ヒントの意味 | |
|---|---|---|
| 最適化アプローチに関するヒント | ALL_ROWS | 最高のスループットとなるように最適化される(全表スキャン、ソート/マージ結合が選択されやすくなる) |
| FIRST_ROWS(n) | レスポンスタイムを最短にするように最適化される(索引スキャンとネステッド・ループ結合が選択されやすくなる) | |
| RULE | ルールベースのアプローチを選択する | |
| アクセス・パスに関するヒント | FULL | 全表スキャンを選択する |
| INDEX | 索引スキャンを選択する | |
| HASH | ハッシュスキャンを選択する | |
| 結合順序に関するヒント | ORDERED | FROM句に指定された順序で表を結合する |
| LEADING | 結合順序の最初の表を指定する | |
| STAR | 可能な場合、スター問い合わせを選択する | |
| 結合方法に関するヒント | USE_NL | ネステッド・ループ結合を選択する |
| USE_MERGE | ソート/マージ結合を選択する | |
| USE_HASH | ハッシュ結合を選択する | |
| そのほかのヒント | APPEND | ダイレクト・パスINSERTを選択する |
| CACHE | 取得されたブロックが、バッファ・キャッシュ内でLRUリストの最後に使用されたものの位置に配置される | |
| 表2 ヒントの種類と意味 | ||
下記は、アクセス・パスおよび結合方法のヒントを指定した例となります。
select /*+ INDEX(d i_department$department_id)
USE_NL(e d) */ |
| リスト2 アクセス・パスと結合方法のヒントを指定 (注:SQLで表の別名を指定している場合には、ヒントも別名で指定する必要があります) |
SQLのチューニングを行ううえでヒントの使用は非常に有効ですが、使用する際には以下の点に注意する必要があります。
2回にわたってSQLチューニングを行ううえで前提となる知識を説明してきましたが、SQLチューニングの目的である「限られたシステム・リソースの中で、最大限のパフォーマンス効果を出すこと」を念頭に置き、チューニング対象となるSQLにとって「最適な実行計画とは何であるか」という点を忘れないでいただきたいと思います。
次回は、日常大量に実行されているSQLの中からチューニング対象のSQLを見つける方法や、これまで説明した実行計画の確認方法について説明します。
Copyright © ITmedia, Inc. All Rights Reserved.