[解決済み] SQL Server - クラスタ化インデックスと非クラスタ化インデックスをいつ使うか？

質問

クラスタ化インデックスと非クラスタ化インデックスの主な違いを知っており、それらが実際にどのように機能するかを理解している。クラスタ化インデックスと非クラスタ化インデックスがどのように読み取りパフォーマンスを向上させるかについて理解しています。しかし、1 つのことは、私が他よりも 1 つを選択する理由は何であるかということで、よくわかりません。

たとえば、次のようになります。テーブルがクラスタ化インデックスを持たない場合、非クラスタ化インデックスを作成する必要がありますか。

どのように解決するのですか？

一言お願いします。 非常に慎重に クラスタ化インデックスを選んでください! クラスタ化インデックスを持つことは多くの処理を高速化するので、すべてのデータテーブルはクラスタ化インデックスを持つべきです。 高速化 挿入や削除でさえもです。しかし、もしあなたが 良い クラスタ化されたインデックスを選んだ場合のみです。

それは 最も複製された データ構造です。クラスタリングキーは、テーブル上のすべての非クラスタリングインデックスの一部でもあります。

クラスタリング キーを選択する際には細心の注意を払う必要があります。

• 狭い (4バイトが理想)

• ユニーク (結局のところ、それは行ポインタです。これを一意にしない場合、SQL Server はバックグラウンドでこれを行い、各エントリに行数と非クラスタ化インデックスの数をかけた数バイトのコストがかかります。）

• 静的 (可能であれば、決して変更しない)

• 理想的には 増え続ける であれば、インデックスの断片化を防ぐことができます（GUID は良いクラスタリングキーの正反対です - この特別な理由から）。

• は非ヌルであるべきで、理想的には固定幅であるべきです。 varchar(250) は非常に貧弱なクラスタリングキーになります。

それ以外のことは、本当にこれらのポイントの後ろにある2番目と3番目のレベルの重要性であるべきです．

Kimberly Trippの一部をご覧ください( インデックスの女王 ) のブログ投稿をご覧ください。彼女がブログで書いたものはすべて、絶対に貴重です。

• PRIMARY KEY および/またはクラスタリング キーとしての GUID
• クラスター化インデックスに関する議論は続く...
• 増え続けるクラスタリングキー - クラスタ化インデックスの議論......再び!
• ディスクスペースは安い - それは ではない がポイントです。