クラスタ化インデックスと非クラスタ化インデックスの違い
私は自分のテーブルに適切なindexを追加する必要があり、いくつかの助けが必要です。
私は混乱しており、いくつかの点を明確にする必要があります。
non-int列にインデックスを使うべきですか？何故私は
clusteredとnon-clusteredindexについてたくさん読んだことがありますが、一方を他方の上に使用するかどうかはまだ決定できません。良い例は私と他の多くの開発者を助けるでしょう。
頻繁に更新される列やテーブルにはインデックスを使用しないでください。テストフェーズに進む前に、他に何を注意しなければならないのでしょうか。
本当に2つの問題を区別する必要があります。
1）primary keyは論理構造-テーブル内のすべての行を一意かつ確実に識別する候補キーの1つです。これは実際には何でも構いません-INT、GUID、文字列-あなたのシナリオにとって最も意味のあるものを選んでください。
2）クラスタリングキー（テーブルの「クラスター化インデックス」を定義する列）-これは物理ストレージ関連のもの。ここでは、小さくて安定した、増え続けるデータ型が最良の選択です-デフォルトオプションとしてINTまたはBIGINT。
既定では、SQL Serverテーブルのプライマリキーはクラスタリングキーとしても使用されますが、そのようにする必要はありません。
私が適用する経験則の1つは次のとおりです。「通常の」テーブル（データの保存に使用するテーブル、つまりルックアップテーブルなど）にはクラスタリングキーが必要です。クラスタリングキーを持たないことは本当に意味がありません。実際には、一般的な考えに反して、クラスタリングキーを使用すると、実際にはすべての一般的な操作-挿入と削除さえもスピードアップします（テーブル構成が異なり、通常はheapよりも優れているため-クラスタリングキーのないテーブル）。
Kimberly Tripp、インデックス作成の女王 には、クラスタリングキーを使用する理由と、クラスタリングキーとして最適なカラムの種類に関する非常に多くの優れた記事があります。テーブルごとに1つしか取得できないため、クラスタリングキーだけでなく、rightクラスタリングキーを選択することが最も重要です。
- プライマリキーまたはクラスタ化キーとしてのGUID
- クラスター化インデックスの議論は続く
- 増加するクラスタリングキー-クラスター化インデックスの議論..........もう一度！
- ディスク容量が安い-それはnotポイント！
マーク
クラスタード・インデックスは、ローの格納方法を変更します。 1つの列（または複数の列）にクラスタ化インデックスを作成すると、SQL Serverはその列でテーブルの行を並べ替えます。これは辞書のようなもので、すべての単語が本全体でアルファベット順にソートされています。
一方、非クラスタ化インデックスは、行がテーブルに格納される方法を変更しません。インデックス作成用に選択された列と、データを含むテーブルの行へのポインタを含む、まったく異なるオブジェクトがテーブル内に作成されます。これは本の最後のページの索引のようなもので、キーワードはソートされていて、参照を早くするために本の素材へのページ番号が含まれています。
SQLサーバーのパフォーマンスを向上させるには、インデックスを使用する必要があります。通常これは、テーブル内の行を見つけるために使用される列がインデックス付けされていることを意味します。
クラスタ化インデックスを使用すると、SQL Serverはインデックスの順序に従ってディスク上の行を並べ替えることができます。これは、クラスタ化インデックスの順序でデータにアクセスした場合、データは正しい順序でディスクに存在することを意味します。ただし、クラスタ化インデックスを持つ列が頻繁に変更されると、行がディスク上を動き回るため、オーバーヘッドが発生します。これは一般的にはお勧めできません。
多くのインデックスを持つことも良くありません。維持費がかかります。それで、明白なものから始めて、そしてあなたが欠けているものから利益を得るであろうものを見るためにそれからプロファイルしなさい。あなたは最初からそれらを必要としません、それらは後で追加することができます。
ほとんどの列データ型は索引付け時に使用できますが、小さい列には大きい列よりも索引を付けた方がよいでしょう。また、列のグループにインデックスを作成するのが一般的です（例：国+都市+通り）。
また、テーブルにかなりの量のデータがあるまで、パフォーマンスの問題に気付くことはありません。もう1つ考えるべきことは、SQLサーバーはそのクエリの最適化を適切な方法で実行するために統計を必要とするということです。そのため、必ず生成してください。
非クラスタ化インデックスとクラスタ化インデックスの例との比較
非クラスタ化インデックスの例として、EmployeeID列に非クラスタ化インデックスがあるとします。非クラスタ化インデックスは、の両方の値を格納します。
従業員ID
ANDその値が実際に格納されているEmployeeテーブルの行へのポインタ。しかし一方で、クラスタ化インデックスは実際には特定のEmployeeIDの行データを格納します。したがって、15のEmployeeIDを探すクエリを実行している場合、テーブル内の他の列のデータは次のようになります。
EmployeeName、EmployeeAddressなど
。実際にはすべてクラスタ化インデックス自体のリーフノードに格納されます。
つまり、非クラスタ化インデックスでは、テーブルに格納されているため直接行にアクセスできるだけのクラスタ化インデックスとは対照的に、テーブル内の行へのポインタをたどって他の必要な値を取得する必要があります。クラスタ化インデックス自体と同じ順序。したがって、クラスタ化インデックスからの読み取りは、一般的に非クラスタ化インデックスからの読み取りよりも高速です。
一般的に、主キー（デフォルトではクラスタ化インデックスがある）など、テーブルを検索するために使用される予定のある（多くの）列にインデックスを使用します。たとえば、（擬似コードで）クエリがあるとします。
SELECT * FROM FOO WHERE FOO.BAR = 2
FOO.BARにインデックスを付けたいと思うかもしれません。並べ替えに使用される列では、クラスタ化インデックスを使用する必要があります。クラスタード・インデックスはディスク上のローをソートするために使用されるので、テーブルごとに1つだけ持つことができます。たとえば、次のようなクエリがあるとします。
SELECT * FROM FOO ORDER BY FOO.BAR ASCENDING
FOO.BARのクラスタ化インデックスを検討することをお勧めします。
おそらく最も重要な考慮事項は、クエリにかかる時間です。クエリに時間がかからない場合や使用頻度が低い場合は、インデックスを追加する価値はありません。いつものように、まずプロファイルを作成し、次に最適化します。 SQL Server Studioはどこで最適化するべきかについての提案をすることができます、そして、MSDNはあなたが役に立つかもしれないといういくらかの情報を持っています 1
データはインデックス順に物理的にソートされているため、非クラスタよりも読みやすく、テーブルごとに1つだけ作成できます（クラスタインデックス）。
クラスタインデックスより挿入と更新操作が速いです。 n個の非クラスタインデックスを作成できます。