11

従業員の詳細を格納するSQLServerテーブルがあります。列IDはGUIDタイプで、列EmployeeNumberはINTタイプです。ほとんどの場合、結合と選択基準を実行している間、EmployeeNumberを処理します。

私の質問は、ClusteredIndexをEmployeeNumberに割り当てながら、PrimaryKeyをID列に割り当てることが賢明かどうかです。

4

6 に答える 6

11

はい、非クラスター化主キーを持つことは可能です。また、主キーとは完全に無関係なクラスター化キーを持つことも可能です。デフォルトでは、主キーもクラスター化インデックスキーになりますが、これは必須ではありません。

主キーは論理的な概念です。データモデルでエンティティを参照するために使用されるキーです。
クラスタ化インデックスキーは物理的な概念です。つまり、行をディスクに保存する順序です。

別のクラスター化キーの選択は、主キーよりも狭いクラスター化キーが必要な場合のキー幅など、さまざまな要因によって決まります（クラスター化キーはすべての非クラスター化インデックスで複製されるため、または頻繁な範囲スキャンのサポート（時系列）データが次のようなクエリで頻繁にアクセスされる場合date between '20100101' and '20100201'（クラスター化されたインデックスキーをオンにdateするのが適切です）。

このテーマについては、以前にここで説明しました。クラスター化インデックスはどの列に配置する必要がありますか？も参照してください。。

于 2011-01-04T19:44:13.573 に答える
10

理想的なクラスター化インデックスキーは次のとおりです。

  1. 一連の
  2. 選択的（重複なし、レコードごとに一意）
  3. 狭い
  4. クエリで使用

一般に、GUIDをクラスター化インデックスキーとして使用することは非常に悪い考えです。これは、行が追加されるときに非常に断片化されるためです。

明確にするために編集：

PKとクラスター化されたキーは確かに別個の概念です。PKはクラスター化されたインデックスキーである必要はありません。

私自身の経験での実際のアプリケーションでは、PKと同じフィールドは、上記と同じ基準を満たしているため、クラスター化されたキーである必要があります。

于 2011-01-04T19:29:58.127 に答える
2

まず、このテーブルの主キーとしてGUIDを選択することに不安を感じていると言わざるを得ません。私は、EmployeeNumberがおそらくより良い選択であり、雇用主がとにかく合法的に取得しなければならないSSN（またはATIN）など、従業員に自然に固有のものがそれよりも優れていると思います（少なくとも米国では）。

それはさておき、GUID列に基づいてクラスター化インデックスを作成しないでください。クラスタ化インデックスは、テーブル内の行の物理的な順序を指定します。GUID値は（理論的には）完全にランダムであるため、すべての新しい行はランダムな場所に配置されます。これはパフォーマンスに非常に悪いです。「シーケンシャル」GUIDと呼ばれるものがありますが、これはちょっとしたハックだと思います。

于 2011-01-04T19:28:44.233 に答える
0

クラスタ化インデックスにより、データはこの順序で物理的に保存されます。このため、連続する行の範囲をテストする場合、クラスター化インデックスは非常に役立ちます。

GUIDは、順序付けが適切なパターンではないため、非常に悪いクラスター化インデックスです。エントリの順序が役に立たない限り、Int Identity列はそれほど良くありません（たとえば、最近の採用）

おそらく従業員の範囲を探していないので、頻繁に関心のない従業員のブロックをセグメント化できない限り、クラスター化インデックスがどれであるかはおそらくそれほど重要ではありません（例：退職日）

于 2011-01-04T19:28:57.043 に答える
0

EmployeeNumberは一意なので、PKにします。SQL Serverでは、PKはクラスター化インデックスであることがよくあります。

GUIDへの参加はひどいものです。@JNKはこれによく答えます。

于 2011-01-04T19:36:42.287 に答える
0

主キー以外の何かにクラストインデックスを使用すると、このインデックスを利用するSELECTクエリのパフォーマンスが向上します。

ただし、ほとんどのシナリオでは、更新する特定の行を見つけるために主キーに依存しているため、UPDATEクエリのパフォーマンスは低下します。

インデックスの中央に新しい行を追加すると、多くの行を（物理的に）移動する必要があるため、CREATEクエリのパフォーマンスも低下する可能性があります。新しいレコードは常に最後に追加され、他の行を移動しないため、これは増分のある主キーでは発生しません。

どの種類の操作で最もパフォーマンスが必要かわからない場合は、主キーにクラスター化インデックスを残し、一般的な検索条件で非クラスター化インデックスを使用することをお勧めします。

于 2016-04-26T14:00:38.457 に答える