明らかに、いくつかの異なるインデックスを保持すると、挿入と削除のパフォーマンスに悪影響があります。クエリのパフォーマンスはどうですか:テーブルにあまりにも多くのインデックスを保持することはまったく意味がありますか?インデックスを追加すると(もちろん、インデックスをまったく使用するクエリの場合)、クエリのパフォーマンスは向上しますか?または、すべてのインデックスを調べて取得する必要があるため、インデックスの数が多すぎるとクエリのパフォーマンスが低下する可能性さえあります結果?
テーブルに異なるインデックスがある場合:それらはすべて考慮されますか、それともオプティマイザの観点から最良のものだけですか? Oracleは多次元インデックスを実装していますか?
検討するインデックスが多い場合は、計画の生成にわずかに時間がかかりますが、その差が測定可能な程度に大きいとは思えません。 インデックスを削除する理由 はクエリのパフォーマンスを表示しません。一方、一般的には、クエリをより効率的にするためにインデックスが使用されることがわかっている場合を除き、インデックスを作成しないでください。
Oracle Concepts Guide から、インデックスを作成するための基準を以下に示します。
一般に、次のような状況では、列にインデックスを作成することを検討してください。
インデックス付けされた列は頻繁にクエリされ、テーブル内の行の総数のごく一部を返します。
参照整合性制約がインデックス付きの列に存在します。インデックスは、親テーブルの主キーを更新したり、親テーブルにマージしたり、親テーブルから削除したりする場合に必要となるフルテーブルロックを回避するための手段です。
一意のキー制約がテーブルに配置され、手動でインデックスとすべてのインデックスオプションを指定する必要があります。
クエリ内のテーブルのすべてのインデックスが使用可能かどうかを判断するために検査されるという意味で、すべてのインデックスが考慮されます。有用性を判断するために、さらに調査が可能です。
statistics が最新である限り、コストベースのオプティマイザは、使用するインデックスに関して賢明な決定を行う必要があります。そうでない場合は、 ヒント を使用するときです。クエリを満たすために必要ではない列のインデックスは参照しません。
これは、Application Developer's Guideの Selecting a Index Strategy で見つかりました。そのページは「インデックス戦略の選択」についてです:
各テーブルのインデックス数を制限します
インデックスが多いほど、テーブルの変更時に発生するオーバーヘッドが大きくなります。行が挿入または削除されると、テーブルのすべてのインデックスを更新する必要があります。列が更新されると、列のすべてのインデックスを更新する必要があります。
クエリのインデックスのパフォーマンス上の利点と更新のパフォーマンスオーバーヘッドを比較検討する必要があります。たとえば、テーブルが主に読み取り専用である場合、より多くのインデックスを使用できます。ただし、テーブルが頻繁に更新される場合は、使用するインデックスが少なくなる可能性があります。