私はまだインデックスのより細かい点を学んでいます、そしてこれは私が必要性を見ることができない何かです。うまくいけば、コミュニティは私を正しい方向に向けることができます。
テーブルには6つ以上のフィールドがあります。
Field1はuniqueidentiferであり、PKです。フィールド2と3も一意の識別子です。残りはvarchar/intsであり、私が見る限り無関係です。
3つのインデックスがテーブルに配置されています：Field2のクラスター化されたPK非クラスター化された非一意性Field2およびField3の非クラスター化された非一意性
どのインデックスにも列は含まれていません。
私の質問は、field2に単一のインデックスを付ける理由はありますか？私の理解では、2つの列または1つの列がある場合、インデックスの検索に違いはないはずです。
インデックスを定義する際に列（データ）の数が増加しました。これは、インデックスのサイズが比例して増加することを意味します。したがって、主キー（インデックス）は小さい/整数フィールドに作成することをお勧めします。
たとえば、3つの列でテーブルを検索するとします。
州、郡、郵便番号。
州だけで検索することもあります。州や郡で検索することもあります。州、郡、郵便番号で頻繁に検索します。次に、州、郡、zipのインデックス。これら3つの検索すべてで使用されます。
zipだけでかなり多く検索する場合、zipはそのインデックスの3番目の部分であり、クエリオプティマイザーはそのインデックスを役に立たないと見なすため、上記のインデックスは（とにかくSQL Serverによって）使用されません。
次に、このインスタンスで使用されるZipのみでインデックスを作成できます。
あなたが探している答えは、頻繁に使用するクエリのwhere句とgroupbyに依存するということだと思います。
あなたが正しいです。Field2 と Field3 にインデックスが存在し、含まれる列が同じ (つまり、何もない) という事実を考えると、Field2 だけのインデックスが有用であると考えることができるいくつかの理由があります。
スタージョンの法則は、おそらく何の役にも立たないことを示唆していますが、マーフィーの法則は、それを削除すると何かが壊れることを示唆しています。
私の唯一の懸念は、Field2 が FK であり、それが参照するテーブルで削除が行われた場合、オプティマイザが、Field2 を最初の列として複合インデックスを使用してチェックし、行が何も参照されていないことを確認するのに十分スマートであるかどうかです。削除されました。もちろん、幅の広いインデックスでも、1 ページあたりの行数が少なくなるため、効率は多少低下します。
他に唯一昇順/降順の問題があるかもしれませんが、違いについては言及していません。
冗長なインデックスを削除した後、そのような操作の実行計画と不足しているインデックス DMV を確認できます。
通常は、常に PK、FK から開始するため、基本的な整合性関連の操作はパフォーマンスに問題ありません。次に、読み取りパフォーマンスのために複合インデックスが追加されます。明らかに、その時点で FK インデックスの一部が冗長になり、この状況に陥ります。
Field1 には主キーという名前が付けられており、デフォルト値が newid() である可能性が高いため、インデックスがあります。一意である必要があります。
Field2 にインデックスがある理由は、それが外部キーであり、多くの where 句と内部結合ステートメントで見つかる可能性が高いためです。
Field3 がインデックスを受け取った理由はわかりませんが、where 句で使用されている場合は、そこにあるとよいでしょう。
インデックスは、情報をすばやく見つけるためのものです。すべての where 句を調べて、個々のニーズに最適なインデックスを決定します。