クラスター化インデックスと非クラスター化インデックス？
私はより小さなDBを担当しています。300メガ以上の100メガの100フィートのテーブルで、約45人のユーザーが1日を通してヒットしています。ほとんどが読み取りですが、かなりの数の更新と挿入があります。 DBのパフォーマンスを引き出すために、DBの構造の学習を遅らせてきました。インデックスを確認することから始めるのが良いと聞きました。上記のDBのテーブルのほとんどすべてのインデックスはクラスター化されており、そのうちのいくつかはクラスター化されていません。
クラスター化と非クラスター化に比べて速度の利点はありますか？差分バックアップの前に毎晩インデックスを再編成して再構築するメンテナンスプランがありますが（はい、私は知っています）、インデックスの形成と使用率をよりよく把握するまで、これで十分ですか？
さまざまなインデックスの「パフォーマンス」を表示するのに役立つスクリプトはありますか？どれだけの大きさのワームの缶に自分自身を入れましたか？
クラスター化インデックスは、テーブル内のデータの物理的な順序を決定し、値の範囲を検索することが多い列で特に効率的です。また、インデックス値が一意である場合に特定の行を見つけるのにも効率的です。
通常（例外があります）、クラスター化インデックスは、単調に増加する列（ID列、または値が増加している他の列など）にあり、一意である必要があります。多くの場合、主キーはクラスター化インデックスの理想的な列です（ただし、クラスター化インデックスを一意の識別子/ GUID列に配置しないでください）。
これから MSDNの記事 ：
クラスタ化インデックスを作成する前に、データへのアクセス方法を理解してください。次の場合にクラスター化インデックスの使用を検討してください。
- 多数の個別の値を含む列。
- BETWEEN、>、> =、<、<=などの演算子を使用して値の範囲を返すクエリ。
- 順次アクセスされる列。
- 大きな結果セットを返すクエリ。
- Join句またはGROUPBY句を含むクエリによって頻繁にアクセスされる列。通常、これらは外部キー列です。 ORDERBY句またはGROUPBY句で指定された列のインデックスを使用すると、行が既に並べ替えられているため、SQLServerでデータを並べ替える必要がなくなります。これにより、クエリのパフォーマンスが向上します。
- 通常は主キーを使用して、非常に高速な単一行ルックアップが必要なOLTPタイプのアプリケーション。主キーにクラスター化インデックスを作成します。
クラスター化インデックスは、次の場合には適していません。
- 頻繁に変更される列：これにより、行全体が移動します（SQL Serverは行のデータ値を物理的な順序で保持する必要があるため）。これは、データが不安定になる傾向がある大量のトランザクション処理システムで重要な考慮事項です。
- ワイドキー：クラスター化インデックスのキー値は、すべての非クラスター化インデックスによってルックアップキーとして使用されるため、各非クラスター化インデックスリーフエントリに格納されます。
SQLServerpedia.comには、インデックス調整に関するいくつかの優れた記事/チュートリアルがあります。 インデックス関連のDMVクエリ および 最適なパフォーマンスのための適切なインデックスの使用 。
代理キーを使用し、その列でクラスター化インデックスを使用することをお勧めします。通常、これは自動インクリメント（IDENTITY）するint列、または一意の識別子になります（後でパフォーマンスの問題を回避するために、順次GUIDにします）。
そうすることで、クエリはテーブル全体でこれらの代理キーに対してJOINを実行し、パフォーマンスとスケーラビリティを提供します。
他の（クラスター化されていない）インデックスに関しては、その選択は顧客がアプリケーションをどのように使用するかによって異なります。インデックスが多すぎると、挿入/更新に支障をきたします。インデックスが不十分な場合、読み取りが遅くなります。 2つのバランスを見つける必要があります。検索と組み合わせて使用される列は、複合（複数列）インデックスを含むインデックス作成の論理的な候補です（その場合は、列の順序に注意してください）。
ファンシーになりたい場合は、履歴データをレポートするための別のOLAPデータベースを用意してください。