web-dev-qa-db-ja.com

複合キーをサロゲートに置き換える

次の表には、数百万行が含まれており、事実上常に99％断片化されています。私の計画は、IDENTITYフィールドを代理キーとして挿入して現在の複合6フィールドのプライマリを置き換え、現在のキーを参照整合性のための一意のキーにして、インデックスを再作成することでした。

    CREATE TABLE [dbo].[Autocompleter](
        [CountryId] [int] NOT NULL,
        [ProvinceId] [int] NOT NULL,
        [LocationId] [int] NOT NULL,
        [PlaceId] [int] NOT NULL,
        [EstabId] [int] NOT NULL,
        [LocaleId] [int] NOT NULL,
        [Title] [varchar](400) NOT NULL,
        [Hotels] [int] NULL,
        [AlternateTitles] [varchar](4000) NULL,
        [EnableHotels] [bit] NOT NULL,
        [EnableHolidays] [bit] NOT NULL,
        [DisplayPriority] [int] NOT NULL,
     CONSTRAINT [PK_autocompleter_1] PRIMARY KEY CLUSTERED 
    (
        [CountryId] ASC,
        [ProvinceId] ASC,
        [LocationId] ASC,
        [PlaceId] ASC,
        [EstabId] ASC,
        [LocaleId] ASC
    )

私が気をつけるべき落とし穴はありますか？ IDフィールドの場合、テーブルに挿入するコードを壊してはならないと思います（列を明示的に指定している限り）

サロゲートキーに新しいクラスター化インデックスを作成してから、6つのフィールドの現在のクラスター化インデックスをNCインデックスにする予定です。

sql-serverdatabase-designprimary-keyfragmentationsurrogate-key
1
DamagedGoods

キンボールの次元モデリングを読み、代理キー、特にIDENTITYを使用すると、リーフページの最後に行を追加するのではなく、中央に行を挿入しようとするため、ページ分割によって引き起こされる断片化を減らすのに役立ちます。キーはインデックスの順序ではありません（インデックスの定義方法に応じて昇順または降順）。

ただし、代理キーが他のテーブルとの結合またはWHERE基準で使用されない場合、クラスター化されたインデックスとして代理キーを使用しても、最初のデータインポート後に追加の利点が得られない可能性があります。複合クラスター化キーを保持する場合は、インポート前に6列の複合キーの順序でソースデータを並べ替えることで、目撃しているページ分割の断片化を回避できます。

クラスター化されたインデックスの選択に関しては、WHERE基準または結合の最も一般的/重要なクエリで使用される列が最適な候補となる可能性があります。 NCIを使用するには、結果セットで必要に応じて、テーブルの残りの値を取得するためにブックマークルックアップが必要になります。

1
MattyZDBA