クラスター化された各インデックスに対して、クラスター化インデックスと追加の重複インデックスが存在するデータベースを継承しました。SQL Server 2000インデックス - クラスタ化と非クラスタ化
つまり IX_PrimaryKeyは列IDのクラスタードインデックスです。 IX_IDは列IDの非クラスタ化インデックスです。
これらの重複していないクラスタ化インデックスをクリーンアップしたいと思います。誰かがこれを行う理由を考えることができるかどうかを確認したいと思います。
誰でもこれを行うためのパフォーマンスの利点を考えることができますか？
完全に同じインデックスの場合、パフォーマンスは向上しません。実際には、挿入と更新時にのパフォーマンス低下が発生します。ただし、列の順序が異なる複数列の索引がある場合は、妥当な理由がある可能性があります。
多分私は十分に懸命に考えていませんが、私はこれを行う理由はありません。クラスタード・インデックスの性質は、データがインデックスの順に整理されていることです。余分なインデックスは完全な無駄であるようです。 BOLを掘りと、この質問を見て
、しかし...
は、これを行うための賢明な理由があるようだしないと、パフォーマンスヒットがあります。
これを行うために私が考えることができる唯一のことは、1ページあたりの行が非常に高く、非常にスキャン/シークが速くなるように非常に狭い行幅のインデックスを作成することです。しかし、他のフィールドは含まれていないので（同じ値であるクラスタ化されたキーを除いて）、私はまだその理由を見ることができません。
元の作成者は、PKがクラスタ化インデックスにデフォルト設定されていて、それが複製であることを認識せずにNCインデックスを作成したことを認識していない可能性があります。
プライマリキー制約が指定されているとSQL Serverが自動的にクラスタ化インデックスを作成したと仮定します（クラスタ化されていない別のインデックスが存在しない場合に発生します）プライマリキー列の非クラスタ化インデックスが作成されている可能性があります。
このようなシナリオが考え：挿入/削除/更新が発生したときにインデックスが更新されるよう
歓声
クラスタ化された主キーを作成するには、廃棄物となります。 WHERE ID = 10を使用してレコードを検索するクエリがないかぎり？
WHERE City = 'Sydney'で頻繁に照会される列にクラスタード・インデックスを作成することができます。 Clusteredとは、SQLがクラスタード・インデックスに基づいてテーブル内のデータをグループ化することを意味します。表のCity値をグループ化すると、SQLはデータをより迅速に検索できます。
同じデータに2つのインデックスを格納することは、ディスクスペースとデータを維持するために必要な処理の浪費です。
しかし、私はIX_PrimaryKeyという名前のインデックスの存在に依存する製品を想像することができます。例えば。
string queryPattern = "select * from {0} as t with (index(IX_PrimaryKey))";
あなたは葉が実際のデータであるため、クラスタ化インデックス自体は、他よりもはるかに少ないスペースを占有するという議論をすることができます。一方、クラスタード・インデックスはページ分割の影響を受けやすく、一部のインデックスはクラスター化されていない方が優れています。
、私は間違いなく重複したインデックスを削除すると悪いことだろうシナリオを考えることができます。
IX_PrimaryKeyの有無を使用してテーブルをある程度扱うコード。私はこれらの優れたデザインは考えていませんが、誰かがそれをやっていることは間違いありません。 （あなたはDailyWTFに投稿しましたか？）
を、それが同一でないインデックスが重複していることは理にかなって例があります。
create index IX_1 on table1 (ID)
create index IX_2 on table1 (ID, TYPE, ORDER_DATE, TOTAL_CHARGES)
あなたは厳密IDで見上げている場合は、SQLを最適化し、使用することができますIX_1。 ID, TYPE, ORDER_DATEに基づいてクエリを実行していて、合計がTOTAL_CHARGESである場合、SQLはIX_2を「カバリングインデックス」として使用して、テーブルに触れることなくインデックスのすべてのクエリの詳細を満たすことができます。一般に、これは広範なテストの後、パフォーマンスチューニングの過程で追加するものです。
全く同じフィールドで2つのインデックスの例を見ても、私はぴったりです。おそらく、SQLはIX_PrimaryKeyで値の存在をチェックし、何らかのブロッキングをバイパスする際に "カバーインデックス"としてIX_IDを使用できますか？
私はDailyWTFを考えていましたが、それはちょっと意味があると思っていました。:) – GordyII