clusteredaと a はどう違いnon-clustered indexますか?
Eric Labashosky
質問する
292398 次
13 に答える
284
クラスタ化インデックス
- 1テーブルにつき1つだけ
- データはインデックス順に物理的に格納されるため、クラスター化されていない場合よりも読み取りが高速
非クラスター化インデックス
- 1テーブルにつき何度でもご利用いただけます
- クラスター化インデックスよりも挿入操作と更新操作が高速
どちらのタイプのインデックスでも、インデックスを使用するフィールドを含むデータを選択する場合のパフォーマンスは向上しますが、更新および挿入操作は遅くなります。
挿入と更新が遅いため、クラスタ化インデックスは、通常は増分であるフィールド、つまり Id または Timestamp に設定する必要があります。
通常、SQL Server はインデックスの選択性が 95% を超える場合にのみインデックスを使用します。
于 2008-09-18T11:20:23.067 に答える
86
クラスター化インデックスは、ディスク上のデータを物理的に並べ替えます。つまり、インデックスに余分なデータは必要ありませんが、クラスター化されたインデックスは 1 つしか存在できません (明らかに)。クラスター化インデックスを使用してデータにアクセスするのが最も高速です。
他のすべてのインデックスは、クラスター化されていない必要があります。非クラスター化インデックスには、実際のデータ行へのポインター (存在する場合はクラスター化インデックスへのポインター) と共に順序付けられたインデックス付き列からのデータの複製があります。つまり、非クラスター化インデックスを介してデータにアクセスするには、追加の間接レイヤーを通過する必要があります。ただし、インデックス付きの列で使用可能なデータのみを選択すると、複製されたインデックス データから直接データを取得できます (そのため、* を使用せずに必要な列のみを SELECT することをお勧めします)。
于 2008-09-18T11:24:10.810 に答える
37
クラスター化されたインデックスは、テーブルに物理的に格納されます。これは、それらが最も高速であることを意味し、テーブルごとにクラスター化インデックスを 1 つしか持つことができません。
非クラスター化インデックスは個別に格納され、必要な数だけ持つことができます。
最適なオプションは、最も使用頻度の高い一意の列 (通常は PK) にクラスター化インデックスを設定することです。非常に説得力のある理由 (1 つも考えられませんが、そこにある可能性があります) がない限り、テーブルには常に適切に選択されたクラスター化インデックスを含める必要があります。
于 2008-09-18T11:19:09.000 に答える
30
クラスタ化インデックス
- テーブルのクラスター化インデックスは 1 つだけです。
- 通常、主キーで作成されます。
- クラスター化インデックスのリーフ ノードには、データ ページが含まれます。
非クラスター化インデックス
- テーブルには 249 個の非クラスター化インデックスしか存在できません (SQL バージョン 2005 以降のバージョンが最大 999 個の非クラスター化インデックスをサポートするまで)。
- 通常、任意のキーで作成されます。
- 非クラスター化インデックスのリーフ ノードは、データ ページで構成されません。代わりに、リーフ ノードにはインデックス行が含まれます。
于 2013-02-10T14:22:31.823 に答える
26
クラスタ化インデックス
- 1 つのテーブルに存在できるクラスター化インデックスは 1 つだけです
- レコードをソートし、順序に従って物理的に保管します
- 非クラスター化インデックスよりも高速なデータ取得
- 論理構造を保存するための余分なスペースは必要ありません
非クラスター化インデックス
- テーブルには任意の数の非クラスター化インデックスを含めることができます
- 物理的な順序には影響しません。データ行の論理的な順序を作成し、物理データ ファイルへのポインターを使用する
- データの挿入/更新はクラスター化インデックスよりも高速です
- 余分なスペースを使用して論理構造を保存する
これらの違いとは別に、テーブルがクラスター化されていない場合 (テーブルにクラスター化インデックスがない場合)、データ ファイルは順序付けされておらず、データ構造としてヒープ データ構造を使用することを知っておく必要があります。
于 2016-06-22T16:29:42.180 に答える
13
長所：
クラスター化されたインデックスは、範囲に対してうまく機能します (たとえば、select * from my_table where my_key between @min と @max)
条件によっては、orderby ステートメントを使用すると、DBMS が並べ替えを行う必要がなくなります。
短所：
新しいキーが順番どおりでない場合、レコードが挿入されるときにレコードの物理レイアウトを変更する必要があるため、クラスター化されたインデックスは挿入を遅くする可能性があります。
于 2008-09-18T11:22:21.270 に答える
12
クラスター化とは、基本的に、データがテーブル内でその物理的な順序になっていることを意味します。これが、テーブルごとに 1 つしか持てない理由です。
クラスター化されていないということは、それが「唯一の」論理的な順序であることを意味します。
于 2008-09-18T11:20:41.990 に答える
8
クラスター化インデックスは、実際にはレコードがディスクに物理的に格納される順序を記述しているため、1 つしか持てません。
非クラスター化インデックスは、ディスク上の物理的な順序と一致しない論理的な順序を定義します。
于 2008-09-18T11:19:57.733 に答える
8
インデックス付きデータベースには 2 つの部分があります。任意の順序で配置された物理レコードのセットと、何らかの基準でソートされた結果を得るためにレコードを読み取る順序を識別するインデックスのセットです。物理的な配置とインデックスの間に相関関係がない場合、すべてのレコードを順番に読み取るには、多くの独立した単一レコードの読み取り操作が必要になる場合があります。データベースは、連続していない 2 つのレコードを読み取るよりも短い時間で数十の連続したレコードを読み取ることができるため、インデックス内で連続しているレコードがディスクにも連続して格納されていると、パフォーマンスが向上する可能性があります。
たとえば、クラスター化されていない空のデータベースから始めて、ランダムな順序で 10,000 レコードを追加すると、レコードは追加された順序で最後に追加される可能性があります。データベースをインデックス順に読み取るには、1 レコードの読み取りが 10,000 回必要です。ただし、クラスター化されたデータベースを使用する場合、システムは各レコードを追加するときに、前のレコードが単独で保存されているかどうかを確認する場合があります。その場合は、データベースの最後に新しいレコードと共にそのレコードを書き込む可能性があります。次に、移動されたレコードが存在していたスロットの前の物理レコードを調べ、その後に続くレコードが単独で格納されているかどうかを確認できます。その場合は、そのレコードをその場所に移動できます。この種のアプローチを使用すると、多くのレコードがペアでグループ化されます。
実際には、クラスター化されたデータベースはこれよりも高度なアルゴリズムを使用します。ただし、注意すべき重要な点は、データベースの更新に必要な時間と、データベースを順次読み取るのに必要な時間の間にはトレードオフがあるということです。クラスター化されたデータベースを維持すると、並べ替え順序に影響を与える方法でレコードを追加、削除、または更新するために必要な作業量が大幅に増加します。データベースが更新されるよりもはるかに頻繁に順次読み取られる場合、クラスタリングは大きなメリットとなります。頻繁に更新されるが、順番に読み込まれることはめったにない場合、特に項目がデータベースに追加される順序がクラスター化インデックスに関する並べ替え順序とは無関係である場合、クラスタリングはパフォーマンスを大きく低下させる可能性があります。
于 2013-09-17T15:48:37.127 に答える
6
クラスター化インデックスは、基本的に、インデックス付きの列内のデータの並べ替えられたコピーです。
クラスター化インデックスの主な利点は、クエリ (シーク) がインデックス内のデータを見つけるときに、そのデータを取得するために追加の IO が必要ないことです。
特に頻繁に更新されるテーブルでは、クラスター化インデックスを維持するオーバーヘッドがパフォーマンスの低下につながる可能性があるため、非クラスター化インデックスを作成することをお勧めします。
于 2008-09-18T11:22:08.057 に答える