2

これからアドバイスをお願いします。オブジェクトを追跡したいテーブルと、オブジェクトに関連するキーのリストを取得しました。例：

OBJECTID   ITEMTYPE   ITEMKEY
--------   --------   -------
1          1          THE
1          1          BROWN
1          2          APPLE
1          3          ORANGE
2          2          WINDOW

OBJECTIDとITEMKEYはどちらも高い選択性を持っています（つまり、OBJECTIDとITEMKEYは非常に多様です）。私のアクセスは2つの方法です：

  • オブジェクトID別：オブジェクトが変更されるたびに、キーのリストが変更されるため、オブジェクトIDに基づいてキーが必要になります。変更は頻繁に発生します。

  • ITEMKEYによる：これはキーワード検索用であり、頻繁に発生します。

したがって、おそらく2つのキーが必要であり、クラスター化されたインデックス用に1つを選択します（より頻繁にアクセスされるキー、または速度を上げたい場所で、今のところ、クラスター化されたオブジェクトIDを優先すると仮定します）。私が混乱しているのは、それをどのように設計すべきかということです。

私の質問は、どちらが良いかです：

a）（OBJECTID、ITEMTYPE、ITEMKEY）のクラスター化されたインデックス、次に（ITEMKEY）のインデックス。私の懸念は、クラスター化されたインデックスが非常に大きいため（2 int、1 string）、すべてのインデックス項目がクラスター化されたキーを指すようになるため、インデックスが大きくなることです。

b）実行中のID DIRECTORYID（整数）を主キーおよびクラスター化インデックスとして使用して新しい列を作成し、（OBJECTID、ITEMTYPE、ITEMKEY）と（ITEMKEY）の2つのインデックスを宣言します。これにより、インデックススペースが最小限に抑えられますが、ルックアップコストが高くなります。

c）（OBJECTID、ITEMTYPE、ITEMKEY）のクラスター化インデックス、およびその上の（ITEMKEY、ITEMTYPE、OBJECTID）のマテリアライズド・ビュー。私の論理では、これはキールックアップを回避し、オーバーヘッドが高くなる代わりに、a）のルックアップを使用したインデックスと同じ大きさになります。

d）えーと...要件を考えるともっと良い方法があるのでしょうか？

よろしくお願いします、アンドリュー

4

1 に答える 1

1

可能であれば、クラスター化されたキーはテーブル上のすべての非クラスター化されたインデックスにも追加されるため、できるだけ小さくするようにしてください。

したがって、可能であればINTを使用するか、2つのINTの組み合わせを使用VARCHARしますが、列が潜在的に幅が広く（> 10文字）、変更される可能性がある場合は、列を使用することはありません。

だからあなたが提示するオプションの中で、私は個人的にb）を選ぶでしょう-なぜ??

サロゲートを追加するDirectoryIDと、クラスタリングキーのすべての重要な基準が満たされます。

  • 小さい
  • 安定
  • 個性的
  • 増え続ける

また、他の非クラスター化インデックスへの影響は最小限に抑えられます。

SQL Serverテーブルで適切なクラスタリングキーを選択するための主な基準については、 KimberlyTrippの優れたブログ投稿を参照してください。非常に便利でわかりやすいです。

クエリ要件を満たすために、2つの非クラスター化インデックスを追加します。1つはObjectID（おそらく頻繁に必要とされる他の列を含む）、もう1つはItemKeyキー名で検索します。

于 2010-10-03T08:29:08.383 に答える