[解決済み] データベースのインデックスはいくつあっても足りない？

質問

私は、かなり大規模な Oracle データベース (ただし、私の質問は他のデータベースにも同様に当てはまります) を使用するプロジェクトに取り組んでいます。 私たちは、ユーザーがフィールドのほぼすべての可能な組み合わせで検索できるようにする Web インターフェイスを持っています。

これらの検索を高速化するために、ユーザーが一般的に検索すると思われるフィールドおよびフィールドの組み合わせにインデックスを追加しています。 しかし、顧客がこのソフトウェアをどのように使用するのかがよく分からないため、どのインデックスを作成すべきかを判断するのは困難です。

スペースは心配ありません。4 テラバイトの RAID ドライブがありますが、使っているのはそのうちのほんの一部だけです。 しかし、あまりに多くのインデックスを持つことによるパフォーマンスへの悪影響が心配です。 これらのインデックスは、行が追加、削除、または修正されるたびに更新される必要があるので、1 つのテーブルに何十ものインデックスを持つことは良い考えではないと想像しています。

では、何個のインデックスが多すぎると考えられるでしょうか？ 10? 25? 50? それとも、本当によくある明らかなケースだけを取り上げて、それ以外は無視すべきなのでしょうか？

どのように解決するのですか？

テーブル上で発生する操作に依存します。

SELECTがたくさんあって、変更がほとんどない場合、好きなだけインデックスを作成してください...これらはSELECT文の速度を上げる（可能性がある）でしょう。

テーブルがUPDATE、INSERT、DELETEによって激しくヒットする場合...これらのオペレーションが行われるたびにすべて修正される必要があるため、多くのインデックスを使用すると非常に遅くなります。

とはいえ、何もしないテーブルに多くの無意味なインデックスを追加することは可能です。 2 つの異なる値を持つ列に B-Tree インデックスを追加しても、データを検索するという点では何も追加されないので、無意味です。 列の値がよりユニークであればあるほど、インデックスの恩恵を受けることになります。