11

通常、クラスター化インデックスは SQL Server Management Studio で主キーを設定することによって作成されますが、PK <-> クラスター化インデックス ( Microsoft SQL Server 2008 の主キーの意味)に関する私の最近の質問では、PK を設定する必要がないことが示されています。クラスター化インデックスが等しくなるようにします。

では、クラスター化インデックスをどのように選択すればよいでしょうか。次の例を見てみましょう。

create table Customers (ID int, ...)
create table Orders (ID int, CustomerID int)

通常は両方の ID 列に PK/CI を作成しますが、CustomerID の注文用に作成することを考えました。それが最良の選択ですか？

4

3 に答える 3

13

The Queen Of Indexing - Kimberly Tripp -によると、彼女がクラスタ化されたインデックスに求めるものは主に次のとおりです。

  • 個性的
  • 狭い
  • 静的

また、次のことも保証できる場合:

  • 増え続けるパターン

そうすれば、理想的なクラスタリング キーにかなり近づきます。

ここで彼女のブログ投稿全体をチェックしてください。また、クラスター化がテーブル操作に及ぼす重要な影響についての別の非常に興味深い投稿をここで確認してください: The Clustered Index Debate Continues .

INT (特に INT IDENTITY) や、場合によっては INT と DATETIME のようなものは、理想的な候補です。他の理由から、GUID はまったく適切な候補ではありません。そのため、PK として GUID を使用している可能性がありますが、その上にテーブルをクラスター化しないでください。認識できないほど断片化され、パフォーマンスが低下します。

于 2010-02-15T16:47:27.073 に答える
6

インデックスの最適な候補はCLUSTERED、レコードを最も頻繁に参照するために使用するキーです。

PRIMARY KEY検索および/またはFOREIGN KEY関係で使用されるものであるため、通常、これはです。

あなたの場合、Orders.ID検索と参照に参加する可能性が最も高いため、クラスタリング式になるための最良の候補です。

CLUSTEREDにインデックスを作成するOrders.CustomerIDと、次のことが起こります。

  1. CustomerIDは一意ではありません。一意性を確保するために、 と呼ばれる特別な隠し32-bit列uniquifierが各レコードに追加されます。

  2. テーブル内のレコードは、この列のペアに従って格納されます(CustomerID, uniquifier)。

  3. レコード ポインタとして、セカンダリ インデックスOrder.IDが作成されます。(CustomerID, uniquifier)

  4. 次のようなクエリ:

    SELECT  *
FROM    Orders
WHERE   ID = 1234567

    Clustered Seekすべての列が のインデックスに格納されているわけではないため、は外部操作 a を実行する必要がありますID。すべての列を取得するには、最初にレコードをクラスター化されたテーブルに配置する必要があります。

この追加の操作には、テーブル内のレコードの総数の最初とIndexDepth同じくらい多くのページ読み取りが必要です。Clustered SeekIndexDepthO(log(n))

于 2010-02-15T16:36:31.213 に答える
1

クラスタリングに関心がある場合、通常はデータ取得の改善に役立ちます。あなたの例では、おそらく特定の顧客のすべてのレコードが一度に必要になるでしょう。customerID でクラスタリングすると、これらの行がファイル内の複数のページに散在するのではなく、同じ物理ページに保持されます。

ROT: コレクションを表示したいものをクラスター化します。発注書の明細は典型的な例です。

于 2010-02-15T16:36:05.137 に答える