私はDBにあまり触れておらず、DBをアプリケーションプログラマとしてのみ使用しています。私が知りたいClusteredとNon clustered indexes。私はグーグルで私が見つけたものは：
クラスター化インデックスは、テーブル内のレコードが物理的に格納される方法を並べ替える特別な種類のインデックスです。したがって、テーブルにはクラスタ化インデックスを1つだけ含めることができます。クラスタ化インデックスのリーフノードには、データページが含まれています。非クラスタ化インデックスは、インデックスの論理的な順序がディスク上の行の物理的な格納順序と一致しない特殊なタイプのインデックスです。非クラスター化インデックスのリーフノードは、データページで構成されていません。代わりに、リーフノードにはインデックス行が含まれます。
私がSOで見つけたのは、クラスター化インデックスと非クラスター化インデックスの違いは何ですか？。
誰かが簡単な英語でこれを説明できますか？
回答:
クラスタ化インデックスでは、行はインデックスと同じ順序でディスクに物理的に格納されます。したがって、クラスター化インデックスは1つしか存在できません。
非クラスター化インデックスでは、物理的な行へのポインターを持つ2番目のリストがあります。多くの非クラスター化インデックスを使用できますが、新しいインデックスを作成するたびに、新しいレコードの書き込みにかかる時間が長くなります。
すべての列を取得したい場合は、通常、クラスター化インデックスから読み取る方が高速です。最初にインデックスに移動し、次にテーブルに移動する必要はありません。
データを再配置する必要がある場合、クラスター化インデックス付きのテーブルへの書き込みは遅くなる可能性があります。
クラスタ化インデックスとは、実際にはディスク上で互いに近い近い値を格納するようにデータベースに指示していることを意味します。これには、ある範囲のクラスター化インデックス値に該当するレコードを迅速にスキャン/取得できるという利点があります。
たとえば、CustomerとOrderという2つのテーブルがあるとします。
Customer
----------
ID
Name
Address
Order
----------
ID
CustomerID
Price特定の顧客のすべての注文をすばやく取得したい場合は、Orderテーブルの "CustomerID"列にクラスター化インデックスを作成できます。このようにして、同じCustomerIDを持つレコードは、物理的に互いに近接してディスク（クラスター）に格納され、検索が高速化されます。
PS CustomerIDのインデックスは明らかに一意ではないため、インデックスを「一意化」するために2番目のフィールドを追加するか、データベースにそれを処理させる必要がありますが、それは別の話です。
複数のインデックスについて。これは、データが物理的に配置される方法を定義するため、テーブルごとに1つのクラスター化インデックスのみを持つことができます。たとえが必要な場合は、テーブルがたくさんある大きな部屋を想像してみてください。これらのテーブルを配置して複数の行を形成するか、それらをまとめて大きな会議用テーブルを形成することができますが、両方を同時に行うことはできません。テーブルは他のインデックスを持つことができ、それらはクラスタ化インデックスのエントリをポイントし、最終的に実際のデータの場所を最終的に示します。
SQL Serverの行指向ストレージでは、クラスター化インデックスと非クラスター化インデックスの両方がBツリーとして編成されます。
（画像ソース）
クラスタ化インデックスと非クラスタ化インデックスとの間の主な違いは、クラスタ化インデックスのリーフレベルがことであるであるテーブル。これには2つの意味があります。
非クラスター化インデックスは、INCLUDE句（SQL Server 2005以降）を使用してすべての非キー列を明示的に含めることによってポイント1を実行することもできますが、それらはセカンダリ表現であり、常にデータの別のコピー（テーブル自体）があります。
CREATE TABLE T
(
A INT,
B INT,
C INT,
D INT
)
CREATE UNIQUE CLUSTERED INDEX ci ON T(A,B)
CREATE UNIQUE NONCLUSTERED INDEX nci ON T(A,B) INCLUDE (C,D)上記の2つのインデックスはほぼ同じになります。上位レベルのインデックスページにはキー列の値が含まれA,B、リーフレベルページにはA,B,C,D
データ行自体は1つの順序でしか並べ替えることができないため、テーブルごとにクラスター化インデックスは1つしか存在できません。
上記のSQL Server Booksオンライン引用は、多くの混乱を引き起こしています。
私の意見では、それは次のように表現される方がはるかに良いでしょう。
クラスタ化インデックスのリーフレベルの行があるため、テーブルごとに1つだけクラスタ化インデックスが存在することができますテーブル行。
書籍のオンライン見積もりは不正確ではありませんが、非クラスター化インデックスとクラスター化インデックスの両方の「ソート」は物理的ではなく論理的であることを明確にする必要があります。リンクされたリストに従ってリーフレベルでページを読み取り、スロット配列順にページの行を読み取る場合、インデックス行をソート順に読み取りますが、物理的にページはソートされない場合があります。クラスター化されたインデックスでは、行は常にインデックスキーがfalse であるのと同じ順序でディスクに物理的に格納されるという一般的な見方です。
これはばかげた実装になります。たとえば、4GBのテーブルの途中に行が挿入された場合、SQL Serverは、ファイルに2GBのデータをコピーして、新しく挿入された行のためのスペースを空ける必要はありません。
代わりに、ページ分割が発生します。クラスター化インデックスと非クラスター化インデックスの両方のリーフレベルにある各ページにはFile:Page、論理キーの順序で次のページと前のページのアドレス（）があります。これらのページは連続している必要も、キー順である必要もありません。
たとえば、リンクされたページチェーンは 1:2000 <-> 1:157 <-> 1:7053
ページ分割が発生すると、新しいページがファイルグループ内の任意の場所から割り当てられます（小さいテーブルの混合エクステント、またはそのオブジェクトに属する空でない均一エクステント、または新しく割り当てられた均一エクステント）。ファイルグループに複数のファイルが含まれている場合、これは同じファイル内にない場合もあります。
論理的な順序と連続性が理想的な物理バージョンと異なる程度は、論理的な断片化の程度です。
新しく作成された単一ファイルのデータベースで、私は以下を実行しました。
CREATE TABLE T
(
X TINYINT NOT NULL,
Y CHAR(3000) NULL
);
CREATE CLUSTERED INDEX ix
ON T(X);
GO
--Insert 100 rows with values 1 - 100 in random order
DECLARE @C1 AS CURSOR,
@X AS INT
SET @C1 = CURSOR FAST_FORWARD
FOR SELECT number
FROM master..spt_values
WHERE type = 'P'
AND number BETWEEN 1 AND 100
ORDER BY CRYPT_GEN_RANDOM(4)
OPEN @C1;
FETCH NEXT FROM @C1 INTO @X;
WHILE @@FETCH_STATUS = 0
BEGIN
INSERT INTO T (X)
VALUES (@X);
FETCH NEXT FROM @C1 INTO @X;
END次に、ページレイアウトを確認しました
SELECT page_id,
X,
geometry::Point(page_id, X, 0).STBuffer(1)
FROM T
CROSS APPLY sys.fn_PhysLocCracker( %% physloc %% )
ORDER BY page_id結果はいたるところにありました。キー順の最初の行（値1-下の矢印で強調表示）は、ほぼ最後の物理ページにありました。
断片化は、インデックスを再構築または再編成して、論理的な順序と物理的な順序の相関を高めることにより、削減または削除できます。
実行した後
ALTER INDEX ix ON T REBUILD;私は以下を得ました
テーブルにクラスタ化インデックスがない場合、それはヒープと呼ばれます。
非クラスター化インデックスは、ヒープまたはクラスター化インデックスのいずれかに構築できます。これらには常に、ベーステーブルに戻る行ロケータが含まれています。ヒープの場合、これは物理的な行識別子（rid）であり、3つのコンポーネント（File：Page：Slot）で構成されます。クラスタ化インデックスの場合、行ロケータは論理的です（クラスタ化インデックスキー）。
後者の場合、非クラスター化インデックスにすでにCIキー列がNCIキー列またはINCLUDE-d列として含まれている場合、何も追加されません。それ以外の場合、欠落しているCIキー列はサイレントにNCIに追加されます。
SQL Serverは常に、キー列が両方のタイプのインデックスに対して一意であることを保証します。ただし、これが一意として宣言されていないインデックスに適用されるメカニズムは、2つのインデックスタイプで異なります。
クラスタ化インデックスはuniquifier、既存の行を複製するキー値を持つすべての行に追加されます。これは単に昇順の整数です。
一意として宣言されていない非クラスター化インデックスの場合、SQL Serverは行ロケーターを非クラスター化インデックスキーに警告なしに追加します。これは、実際に重複している行だけでなく、すべての行に適用されます。
クラスタ化された用語と非クラスタ化された用語は、列ストアインデックスにも使用されます。紙SQL Serverの列ストアの拡張状態
列ストアデータは実際にはどのキーでも「クラスター化」されていませんが、プライマリインデックスをクラスター化インデックスとして参照するという従来のSQL Serverの規則を維持することにしました。
SQL Server 2014。私が得る95%最初の挿入後にインデックスの断片化を。index rebuild断片化された後、0%値が並べ替えられました。疑問に思っているのThe only time the data rows in a table are stored in sorted order is when its clustered index fragmentation is 0ですが、それは言えるでしょうか。
これは非常に古い質問だと思いますが、上記の良い答えを説明するのに役立つアナロジーを提供したいと思いました。
公共図書館に足を踏み入れると、すべての本が特定の順序で配置されていることがわかります（おそらくデューイ10進数システム（DDS））。これは、本の「クラスター化インデックス」に対応しています。必要な本のDDS＃がである場合、005.7565 F736sラベルが付けられている本棚の列などを見つけることから始めます001-099。（スタックの最後にあるこのエンドキャップ記号は、インデックスの「中間ノード」に対応します。）最終的には005.7450 - 005.7600、というラベルの付いた特定の棚にドリルダウンし、次に、指定したDDS＃の本が見つかるまでスキャンし、その時点であなたはあなたの本を見つけました。
しかし、あなたの本のDDS＃が記憶された状態で図書館に来なかった場合は、支援するために2番目の索引が必要になります。昔、図書館の前には「カードカタログ」として知られている素晴らしい引き出しがあります。その中には何千もの3x5カードがあり、各本に1枚ずつ、アルファベット順（おそらくタイトル順）でソートされていました。これは「非クラスター化インデックス」に対応します。これらのカードカタログは階層構造で編成されていたため、各引き出しにはKa - Kl、含まれているカードの範囲（たとえば、「中間ノード」）でラベルが付けられていました。もう一度、あなたの本が見つかるまでドリルインしますが、この場合、あなたがそれを見つけたら（すなわち、「リーフノード」）、あなたはその本自体を持っていません。クラスタ化インデックスで実際の本を見つけるためのインデックス番号（DDS＃）。
もちろん、司書がすべてのカードをコピーして、別のカードカタログで別の順番に並べ替えることを妨げるものはありません。（通常、少なくとも2つのそのようなカタログがありました。1つは作成者名で、もう1つはタイトルで並べ替えられています。）
クラスター化インデックスと非クラスター化インデックスの特徴を以下に示します。
create Index index_name(col1, col2, col.....)。クラスター化インデックス
クラスター化インデックスは、テーブル内のDATAの物理的な順序を決定します。このため、テーブルにはクラスター化インデックスが1つしかありません。
「辞書」他の索引は必要ありません。すでに索引は単語に従っています
非クラスター化インデックス
非クラスター化インデックスは、ブックのインデックスに似ています。データは1か所に保存されます。インデックスは別の場所に格納されており、インデックスにはデータの格納場所へのポインターがあります。このため、テーブルには複数の非クラスター化インデックスがあります。
クラスター化インデックス
クラスター化インデックスは、キー値に基づいてテーブルまたはビューのデータ行を並べ替えて格納します。これらは、インデックス定義に含まれる列です。データ行自体は1つの順序でしか並べ替えることができないため、テーブルごとにクラスター化インデックスは1つしか存在できません。
テーブル内のデータ行が並べ替えられた順序で格納されるのは、テーブルにクラスター化インデックスが含まれている場合のみです。テーブルにクラスター化インデックスがある場合、そのテーブルはクラスター化テーブルと呼ばれます。テーブルにクラスター化インデックスがない場合、そのデータ行はヒープと呼ばれる順序付けられていない構造に格納されます。
非クラスター化
非クラスター化インデックスは、データ行とは別の構造を持っています。非クラスター化インデックスには非クラスター化インデックスのキー値が含まれており、各キー値のエントリには、キー値を含むデータ行へのポインターがあります。非クラスター化インデックスのインデックス行からデータ行へのポインターは、行ロケーターと呼ばれます。行ロケーターの構造は、データページがヒープに格納されているか、クラスター化されたテーブルに格納されているかによって異なります。ヒープの場合、行ロケータは行へのポインタです。クラスター化テーブルの場合、行ロケーターはクラスター化インデックスキーです。
非クラスター化インデックスのリーフレベルに非キー列を追加して、既存のインデックスキー制限をバイパスし、完全にカバーされたインデックス付きクエリを実行できます。詳細については、列が含まれるインデックスの作成を参照してください。インデックスキーの制限の詳細については、SQL Serverの最大容量の仕様を参照してください。
リファレンス：https : //docs.microsoft.com/en-us/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-説明
データベースシステムの 15.6.1から引用した「クラスタリングインデックス」に関する教科書の定義を紹介しましょう。
我々はまた、話すこと、クラスタリング索引の属性にインデックスされているか、このインデックスの検索キーのための固定値を持つタプルのすべては、それらを保持できるように、いくつかのブロックとして大まかに上に表示されていることなどの属性、。
定義を理解するために、教科書が提供する例15.10を見てみましょう。
関係
R(a,b)属性でソートされa、そのために保存されている、ブロックにパックは、必ずクラスタ型です。上のインデックスaはクラスタリングインデックスです。これは、指定されたa-value a1 に対して、その値を持つすべてのタプルaが連続しているためです。したがって、図15.14でa提案されているように、-value a1 を含む最初と最後のブロックを除いて、それらはブロックにパックされて表示されます 。ただし、とbの値が非常に密接に相関していない限り、固定値を持つタプルはファイル全体に分散されるため、bのインデックスはクラスタリングされる可能性は低いです。ab
この定義では、データブロックがディスク上で隣接している必要はありません。それは、検索キーを持つタプルができるだけ少ないデータブロックにパックされることを示しているだけです。
関連する概念は、クラスター化された関係です。タプルを保持できる可能性のあるブロックとほぼ同じ数のブロックにそのタプルがパックされている場合、関係は「クラスター化」されます。言い換えると、ディスクブロックの観点から、異なるリレーションのタプルが含まれている場合、それらのリレーションをクラスター化することはできません（つまり、他のディスクブロックからそのリレーションのタプルをタプルは現在のディスクブロックのリレーションに属していません）。明らかに、R(a,b)上記の例ではクラスター化されています。
2つの概念を結び付けるために、クラスター化された関係は、クラスター化インデックスと非クラスター化インデックスを持つことができます。ただし、非クラスタ化リレーションの場合、インデックスがリレーションの主キーの上に構築されていない限り、クラスタリングインデックスは使用できません。
単語としての「クラスター」は、データベースストレージ側のすべての抽象化レベル（タプル、ブロック、ファイルの3つの抽象化レベル）にまたがって送信されます。「クラスター化ファイル」と呼ばれる概念。ファイル（ブロックのグループ（1つ以上のディスクブロック）の抽象）に、1つの関係または異なる関係のタプルが含まれているかどうかを示します。ファイルレベルであるため、クラスタリングインデックスの概念とは関係ありません。
ただし、一部の教材は、クラスター化されたファイル定義に基づいてクラスター化インデックスを定義することを好みます。これら2つのタイプの定義は、データディスクブロックまたはファイルの観点からクラスター化された関係を定義するかどうかに関係なく、クラスター化された関係レベルでも同じです。この段落のリンクから、
ファイルの属性Aのインデックスは、次の場合にクラスタリングインデックスになります。属性値A = aのすべてのタプルがデータファイルに連続して（=連続して）保存される
タプルを連続して格納することは、「タプルは、それらのタプルを保持できる限りの数のブロックにパックされる」と言うことと同じです（一方はファイルについて話し、もう一方はディスクについて話します）。これは、タプルを連続して格納することが、「それらのタプルを保持できる可能性のある数のブロックにパックされる」ことを実現する方法だからです。
クラスター化インデックス： テーブルにクラスター化インデックスが存在しない場合、主キー制約によりクラスター化インデックスが自動的に作成されます。クラスター化インデックスの実際のデータは、インデックスのリーフレベルで保存できます。
非クラスター化インデックス：非クラスター化インデックスの 実際のデータは、リーフノードで直接見つかりません。実際のデータを指す行ロケーターの値しか含まれていないため、追加の手順を実行して検索する必要があります。非クラスター化インデックスをクラスター化インデックスとして並べ替えることはできません。テーブルごとに複数の非クラスター化インデックスが存在する可能性がありますが、実際には、使用しているSQLサーバーのバージョンによって異なります。基本的に、SQL Server 2005では249の非クラスター化インデックスが許可され、2008、2016などの上記のバージョンでは、テーブルごとに999の非クラスター化インデックスが許可されます。
クラスタ化インデックス -クラスタ化インデックスは、データがテーブルに物理的に格納される順序を定義します。テーブルデータは唯一の方法で並べ替えることができるため、テーブルごとに1つのクラスター化インデックスしか存在できません。SQL Serverでは、主キー制約により、その特定の列にクラスター化インデックスが自動的に作成されます。
非クラスター化インデックス-非クラスター化インデックスは、テーブル内の物理データを並べ替えません。実際、非クラスター化インデックスは1つの場所に格納され、テーブルデータは別の場所に格納されます。これは、本のコンテンツが1か所にあり、索引が別の場所にある教科書に似ています。これにより、テーブルごとに複数の非クラスター化インデックスが可能になります。ここでは、テーブル内でデータがクラスター化インデックスによって並べ替えられることを説明することが重要です。ただし、非クラスター化インデックス内では、データは指定された順序で格納されます。インデックスには、インデックスが作成された列の値と、その列の値が属するレコードのアドレスが含まれます。インデックスが作成された列に対してクエリが発行されると、データベースは最初にインデックスに移動して検索します。テーブル内の対応する行のアドレス。次に、その行アドレスに移動して、他の列値をフェッチします。非クラスタ化インデックスがクラスタ化インデックスよりも遅いのは、この追加のステップが原因です。
クラスター化インデックスと非クラスター化インデックスの違い