クラスタリングされたインデックスの考慮事項別個のバリューと大きな結果セットと監査用の単一の垂直テーブル

Question

私はクラスタードインデックスを作成するためのベストプラクティスを研究していて、かなりリストにあるこれらの2つの提案を完全に理解しようとしていますすべてのブログや記事に関する記事

• 多数の異なる値を含む列。
• 大きな結果セットを返すクエリ。

これらがわずかに反するように見えるか、私は多分それはちょうど..あなたがテーブルにアクセスしているかに依存または「大きな結果セット」は何を意味するかの私の解釈が間違っている推測している....

クラスタ化された列に対して範囲クエリを実行しているのでなければ、通常は重要な結果セットが得られないようです。したがって、SQL ServerがPK上のクラスタード・インデックスをデフォルト設定している場合、大規模な結果セット提案を実行することはめったにありませんが、多くの個別の値が得られます。

質問。このquetionは、我々はそれが表の列を持っている必要があり、縦監査テーブルから茎....このテーブルに対して書かれているすべての単一のクエリは

WHERE TABLE = 'TABLENAME' 

を持っていますが、テーブル名は非常に不明確な...各結果セットです2番目の条件を満たしているようですが、確かにそれほどユニークではありません....つまり、テーブルを大きくするために4バイトのUniquifer（sp？）を追加しなければならないということです。 ..

すべての連絡先または一部のアカウントが1つのテーブルに正規化され、TYPEパラメータで区切られているDBがあると、この状況が数回発生しています。すべてのクエリには....

監査テーブルの場合、クエリは通常、変更された日付、並べ替えられた列、時には変更されたユーザーなどのいずれかによって並べ替えられます。この監査シナリオに

私の他の思考はテーブルが監査され、その後、データの上にインデックス付きビューを生成する間に競合がないので、その挿入が速いので、ちょうど...監査テーブルに

Answer 1

インデックスをHEAPを作ることでしたデザインは科学と同じくらい芸術です。

• テーブルが最も頻繁にアクセスされる方法：ほとんどのインサート

  には、考慮すべき多くのものがありますか？どんな更新？ DML文より多くのSELECT？どの監査テーブルでも、ほとんどの場合、挿入、更新なし、データの期限がない限りほとんど削除されないことがあります。

• クラスタ化インデックスの場合、クラスタ化インデックスの各列のデータは、クラスタ化されていない各インデックスにコピーされます（ただし、UNIQUEインデックスではありません）。これは、クラスタ化されていないインデックスを使用してクエリを処理する場合などに便利です。ただし、クラスタ化されていないインデックスによって占有される物理領域がそれよりも大きくなることも意味します。
• クラスタ化インデックス一般には、UNIQUEキーワードで宣言するか、主キーにする必要があります（例外はありますが）。一意でないクラスタード・インデックスには、ユニークでないキー値を持つ各行をアドレス可能にするために必要な、固有でない4バイトのフィールドがあります。グルーピングは明らかに明白ではないので、単一の行に絞り込むことはまだ範囲です。
• どこでも言及したように、クラスタ化インデックスはデータの物理的な順序付けであり、最良のI/Oが必要なものに対応したいと考えています。これは、一意でないクラスタード・インデックスにオーダーがある直上のポイントにも関係しますが、データが本当にユニークでない場合（ユニークなデータではなく、索引が作成されたときにUNIQUEキーワードが欠落している場合）データを物理的に注文する利点があります。
• 情報や理論にかかわらず、テストテストテスト。あなたの特定の状況に関連する多くの要因が関与しています。

したがって、DateフィールドとTableNameフィールドがあると述べました。 DateとTableNameの組み合わせが一意の場合は、PKまたはUNIQUE CLUSTERED索引で複合キーとして使用する必要があります。そうでなければ、UserIDModifiedのように一意性を作成する別のフィールドを見つけます。

最も推奨事項は（のみによる最初のフィールド上にある統計に）最初の一つとして、最もユニークなフィールドを持つようにしているが、これはすべての状況に当てはまりません。すべてのクエリがTableNameであることを考えれば、データの物理的な順序を利用するために、まずそのフィールドを置くことにします。このようにして、SQL Serverは、ディスク上の他の場所を検索することなく、読み込みごとに関連性の高いデータを読み取ることができます。あなたはおそらくDateで注文しているので、私はそのフィールドを2番目に入れます。最初にTableNameを置くと、最初にDateを置くよりも、より多くの断片化が発生しますが、索引の再構築時には、データが既にグループ化されており（TableName）、照会が期待するように順序付けられている（Date） Dateを最初に置くと、データは正しく並べられますが、問合せを満たすために必要な行はデータファイル全体に広がり、取得にはさらに多くのI/Oが必要になります。また、同じクエリを満たすデータページが増えると、バッファプール内のページが増え、他のページをプッシュしてPLE（Page Life Expectancy）を削減する可能性があります。また、TableName（およびその他のフィルタはDateフィールドを使用しない）を使用するクエリは、クラスタ化インデックスをスキャンするか、または非クラスタ化インデックスをTableNameで作成する必要があるため、すべてのクエリでDateフィールドを強制する必要があります最初です。

私はヒーププラスインデックス付きビューモデルの疲れだろう。はい、挿入用に最適化されている可能性がありますが、システムはヒープに対してすべてのDML文の索引付きビューのデータを保持する必要があります。再度テストする必要がありますが、監査テーブルのクラスタード・インデックスのフィールドの選択肢よりも優れているとは思えません。