私たちのほとんどは、おそらくデータベースインデックスを使用するのが良いことに同意するでしょう。インデックスが多すぎると、パフォーマンスが実際に低下する可能性があります。
原則として、どのフィールドにインデックスを付ける必要がありますか？
どのフィールドにインデックスを付けるべきではありませんか？
パフォーマンスの向上ではなく、パフォーマンスの向上を達成するために、インデックスの数が多すぎて十分ではないというバランスを取りながら、インデックスを使用するためのルールは何ですか？
回答:
「インデックスが多すぎる」というルールは、誤解を招く可能性があります。
平均的なデータベースの約98％の読み取り（またはそれ以上）を考慮すると、読み取りを最適化する必要があります。たとえば、一意のインデックスがある場合、INSERTは読み取りです。または、更新のWHERE。私はかつて、書き込み集中型のデータベースでさえ、85％の読み取りであることを読みました。
あなたが持っているのは質の悪い索引付けです。例：
cold, coleとcold, cole, colf)OLTPシステムであっても、実際のデータの数倍のインデックスを持つことは非常に一般的です。
一般的に、私は
それから私は見てみたい：
それを言って、システムを調整するために物事がどのようにパンアウトしたかを見て（100億行後）、いくつかのシステムについてこれらの規則を破りました。しかし、なぜそうするのかを実証できなければ、インデックスを作成しないとは考えません。
どのインデックスを選択するか、そしてなぜGail Shawが執筆するかについて書かれた最高の記事シリーズの1つです。こちらをクリックして記事を見つけることができます
あなたが尋ねる質問には、50の異なる方法で答えることができます。それは本当にあなたが持っているデータとそれがどのようにクエリされるかということです。一般的なルールは、ヒープを回避するために、各テーブルにクラスター化インデックスを常に用意することです。通常、クラスタ化インデックスはできるだけ小さくする必要があります。テーブルにクラスター化インデックスがある場合、非クラスター化インデックスのリーフページにあるすべてのインデックスレコードは、ブックマーク検索用の各クラスター化インデックスのレコード値を格納します。テーブルがヒープの場合、SQLはブックマーク検索用の一意の識別子を作成します。8バイトまたは16バイトのサイズを思い出せません。これは、INTと言うよりもはるかに大きなデータ型になる可能性があります。ヒープテーブルに8つの非クラスター化インデックスがあることを想像してください。
ここで、データベースごとに異なる戦略が必要であることを付け加えます。たとえば、MySQL w / InnoDBとPostgreSQLを比較してみましょう。
InnoDB
InnoDBテーブルは基本的に、インデックスエントリに行情報を含めるように拡張された主キーのBツリーインデックスです。物理的な順序のスキャンはサポートされておらず、すべてのスキャンは論理的な順序で行われます。これは2つのことを意味します。
Innodbでの順次スキャンは、大量のランダムディスクI / Oを生成し、
主キーインデックスは、セカンダリインデックスを使用しているかどうかに関係なく走査する必要があります。
このモデルでは、他のアプローチよりも主キーの検索が高速です。
この場合、複数ページのテーブルに十分なフィールドのインデックスを作成することが非常に重要です。典型的なルールは、フィルタリングするすべてのものにインデックスを付けることです。
PostgreSQL
PostgreSQLは、ファイルごとに1つのテーブル（一部のテーブルは多数のファイル）のヒープファイルを使用します。ここでは、そのヒープの空き領域からタプルが割り当てられます。物理的な注文スキャンがサポートされています。論理順序スキャンを機能させるには、インデックスを追加する必要があります。
PostgreSQLの主キーは、基本的に値がNULLにならない一意のインデックスのサブセットです。UNIQUE制約は暗黙的なインデックスを使用して行われ、他のいくつかのインデックスタイプはインデックスで可能なさまざまな操作でサポートされます。
これの意味は：
インデックスファイルとテーブルファイルにヒットする合理的に大きなテーブルを前提とするプライマリキールックアップ。これは、インデックスのみをたどる必要があり、行がインデックスに含まれるMySQLのアプローチよりも大幅に遅くなります。
物理的な順序スキャンのパフォーマンスが大幅に向上し、かなりの数の行が処理されるランダムなディスクI / Oが減少します。
セカンダリインデックススキャンは、テーブルの物理的な部分に到達するためにたった1つのインデックスをたどる必要があるため、MySQLのスキャンよりもパフォーマンスが高くなります。
このモデルでは、インデックスが必要になることがよくありますが、プランナはインデックスを使用する自由度が高く、インデックスを使用しない場合の影響はそれほど深刻ではありません。テーブルは（pkeyルックアップに特化するのではなく）より一般的に最適化されているため、必要なインデックスは少なくなります。
TL; DR
あなたのRDBMSを知っています。
Oracle 11.2コンセプトガイドから：
11.2パフォーマンスチューニングガイドから：
11.2管理者ガイドから：