例えば：
Given columns A,B,C,D,
IX_A is an index on 'A'
IX_AB is a covering index on 'AB'
IX_Aは冗長であるため、安全に削除できます。代わりにIX_ABが使用されます。これが一般化するかどうか知りたい：
私が持っている場合：
IX_AB
IX_ABC
IX_ABCD
など、
小さい方のインデックスは引き続き安全に削除できますか？つまり、IX_ABCはIX_ABを冗長にし、IX_ABCDはIX_ABとIX_ABCの両方を冗長にしますか？
一般に、これはサーバーごとに異なりますが、カバーするインデックスは、より小さなインデックスの選択をカバーします。
したがって、a、b、cをカバーするインデックスがある場合、通常は自動的にa、a、bをカバーするインデックスが得られます。
たとえば、b、cのカバーインデックスがあるとは限りません。
はい、ほとんどの場合。
ただし、IX_ABCDは、たとえばIX_BCDの代わりとしてはそれほど役に立ちません。
ただし、注意点があります。インデックスには引き続きディスクの読み取りが必要な場合があるため、CとDがインデックスのサイズを爆発させると、IX_ABCDでA、Bを検索する際に、IX_ABで検索する場合には発生しない非効率性が発生します。 。
ただし、その違いは、IX_ABを個別に維持することによる追加のパフォーマンスヒットによって上回る可能性があります。
重要なのは、インデックスの先頭の列です。インデックスIX_ABCDがある場合、次のクエリはインデックスを使用します。
A=1であるテーブルから*を選択します
A=1およびB=1であるテーブルから*を選択します
A=1およびB=1およびC=1であるテーブルから*を選択します
ただし、以下はインデックスを使用しない可能性が高いです（少なくとも意図した方法ではありません）。
B=1であるテーブルから*を選択します
C=1であるテーブルから*を選択します
B=1およびC=1であるテーブルから*を選択します
重要なことは、先頭の列が使用されることです。したがって、インデックスが作成されるときの列の順序は重要です。
必ずしも。（A、B、C）のインデックスは、Aのフィルタリング述語、Aの順序付け要求、またはAの結合条件に使用できることは事実ですが、必ずしもインデックス（A）だけが役に立たないことを意味するわけではありません。 。（A、B、C）のインデックスが（A）よりもかなり広い場合、Aのみの範囲スキャンでは、読み取るページ数が少なくなるため（インデックスが狭くなるため）、I/Oが大幅に節約されます。
ut私はこれが規則ではなく例外になるだろうと管理しています。一般に、（A、B）に別のインデックスが存在する場合は、Aのインデックスを削除しても安全です。（A、B）のインデックスは、Bのフィルタリングを満たさないため、左端の列が同じである場合にのみ安全に削除できることに注意してください。一部のデータベースには、Bを検索するために（A、B）のインデックスを使用できる「スキップスキャン」演算子がありますが、これは非常に狭い境界の場合です。
データベースエンジンの内部については何も想定せず、実際に使用されているクエリプランを実際に確認するのが常に最善です。