web-dev-qa-db-ja.com

主キーのクラスター化インデックスと非クラスター化インデックス

約1900万件のレコードを含む大きなテーブルがあります。

主キーはuniqueidentifierと呼ばれるID列で、この列には非クラスター化インデックスがあります。アプリケーションはこれらのGUID値を生成します。

現在、テーブルにはクラスター化インデックスがありません。

テーブルには現在クラスター化インデックスがないため、非クラスター化インデックスからクラスター化インデックスへの変更を検討しています。これを行うことの長所と短所は何ですか?

  1. 現状のまま
  2. クラスタ化インデックスを作成する別の列を見つけます
  3. このID列を非クラスター化インデックスからクラスター化インデックスに変更します。

毎日約5万回の挿入があり、削除も更新もありません。追加の詳細が必要な場合はお知らせください。

テーブルには合計24列があり、クラスター化インデックスのない5つの非クラスター化インデックスがあります。

  • インデックス1-IDのPK(uniqueidentifier
  • インデックス2-タイムスタンプ(datetime
  • インデックス3-ハッシュ列(nvarchar(64)
  • インデックス4-カバーするインデックス4列
  • 索引5-カバーする索引6列

私は他の誰かからデータベースを継承しました。アプリケーションはこれをGUIDを主キーとして使用し、それぞれの子テーブル内の一致する外部キーとの関係を持っているため、クエリで結合にuniqueidentifier IDを使用します。

GUIDが連続して生成されているかどうかをどのように判断しますか?それらは似ていないようです。いくつかの例は、createddateで並べられた次のとおりです。

24A689A0-831E-4670-9204-766256C58E43
ED001C69-11BA-430D-ACF9-3C3CADF3B400
768E5497-4F48-4C65-87D9-E9C27066708E

少し調べてみると、uniqueidentifier列はクラスター化インデックスの候補として適切ではないようです。そのため、次のことを行う必要があるかどうか疑問に思っています。

  1. いくつかの列を見て、これらの列に複合クラスター化インデックスを作成するか、
  2. クラスター化インデックスなしでライブ
  3. 他に何か?

追加の詳細情報を提供できるかどうかをお知らせください。この決定を行うための考慮事項について、誰かが私にいくつかのガイダンスを与えることができるならば、私はそれを大いに感謝します。

4
equipe9

順次GUID=生成に切り替えない限り、GUIDをクラスター化インデックスキーとして使用する必要はありません。したがって、選択肢は

1)ID列をクラスター化インデックスキーにします。これにより、IDでの結合と検索が最適化されますが、それらはまれなようです。

2)SQL 2016+の場合、ヒープをクラスター化列ストアインデックスに置き換えます。これにより、データが圧縮され、テーブルスキャンが最適化されます。おそらく、他のインデックスの一部を削除できる程度です。

3)最も使用されている非クラスター化インデックスを選択し、クラスター化インデックスにします。

4)ヒープのままにしておきます。

いずれの場合でも、GUIDを外部キーとして使用する「子テーブル」は、その外部キー列をクラスター化された主キーの先頭列として持つことでメリットが得られる場合があります。

このuniqueidentifierフィールドをこのテーブルのクラスタリングキーとして使用することはお勧めしません。あなたは言及しました:

削除も更新もない、毎日約5万回の挿入を取得しています

これをテーブルのクラスター化インデックスにすることは、テーブル全体がそのフィールドによって順序付けられることを意味します。したがって、挿入が行われるたびに、SQL Serverはインデックス内のその場所にシーク​​し、新しい行をテーブルのその位置に挿入する必要があります。

そして、新しい行を挿入する必要があるデータページにスペースがない場合、スペースを空けるためにデータを移動する必要があります。

理想的には、クラスタリングキーは小さく、一意で、常に増加します。 uniqueidentifierは間違いなく「増え続ける」基準を満たしていません。


ワークロードの「書き込み」部分は挿入のみ(削除や更新なし)のように聞こえるため、このテーブルにはヒープ(クラスター化インデックスがまったくない-現在の状態)が適しています。 SELECTクエリが許容範囲内で実行されている限り。

遅い選択クエリで問題が発生している場合は、それらをサポートするために非クラスター化インデックスを追加するか、上記の要件を満たすクラスター化インデックスを選択する必要があります。

2
Josh Darnell