クラスター化インデックスはどのようにハード ディスクに格納されますか? 論理的な順序は何ですか?
非クラスター化インデックスはどのように機能しますか?
クラスター化インデックスはどのようにハード ディスクに格納されますか? 論理的な順序は何ですか?
非クラスター化インデックスはどのように機能しますか?
これは、テーブル内のデータが(またはクラスタリング列)B-Tree
の順序に従って に格納されることを意味します。CLUSTERED PRIMARY KEY
この名前は、私の意見では少し紛らわしいです。Oracle
と呼ばれるのと同じ概念が、index-organized table
より説明的であることがわかります。
非クラスター化インデックスには、インデックス付き列の値と、元のレコードへのポインターが含まれます。
「クラスター化インデックス」はテーブルそのものです。「非クラスター化」インデックスは、テーブルのいくつかの列の順序付きコピーです。
クラスター化インデックスを「作成」すると、テーブルが再配置されます。そのため、1 つのテーブルに複数の「クラスター化インデックス」を設定することはできません。テーブルを複数の順序で配置することはできません。
セカンダリ インデックスを作成すると、テーブルのシャドウ コピーが作成され、インデックス付きの列の値とその元のレコードへのポインターが保持されます。テーブルが変更されるたびに、コピーも変更されます (エンジンが自動的に処理します)。
id col1 value
-- -- --
1 1 Data 1
6 1 Data 6
3 1 Data 3
7 2 Data 7
9 2 Data 9
5 2 Data 5
テーブルは注文されていません。
id col1 value
-- -- --
1 1 Data 1
3 1 Data 3
5 2 Data 5
6 1 Data 6
7 2 Data 7
9 2 Data 9
テーブルは に注文されていid
ます。
Table Index
id col1 value col1 id
-- -- -- -- --
1 1 Data 1 1 1
3 1 Data 3 1 3
5 2 Data 5 1 6
6 1 Data 6 2 5
7 2 Data 7 2 7
9 2 Data 9 2 9
テーブルはid
で順序付けされ、インデックスは で順序付けられます(col1, id)
非クラスター化インデックスの場合、個別のファイルが作成されます。このファイルには、インデックス フィールドのみが保持され、レコードが論理インデックス順に配置されます。クラスター化インデックスの場合、個別のファイルはありません。テーブル自体のデータ (すべてのフィールド) は、インデックスの論理的な順序で配置されます。
これにより、インデックスの検索が高速になります (ただし、範囲を検索する日付などのインデックスには最適です)。また、レコードが途中で挿入される場合、挿入がかなり遅くなります。
クラスタ化されたインデックス ストレージ
クラスター化されたインデックスは、基本的に他のすべてのインデックスとまったく同じように機能します。それらは、 B-Treeと呼ばれる構造のバリアント内に格納されます。これらは、SQL Server の他のすべてのテーブルと同じ形式で、同じファイルに格納されます。
コンセプト
一歩下がって、インデックスを作成するデータについて考えてみてください。(このアナロジーで本を考えてほしい)。本の巻末に索引を付けるだけでなく、本の中のデータも注文した場合はどうなるでしょうか。より速く情報を検索できます。たとえば、すべてのデータが姓と名の順に並べられている電話帳を考えてみましょう。誰かの番号を見つけるために、電話帳の後ろに行く必要はありません。必要なものを見つけるために本の後ろにある索引に行かなければならない歴史の本とは対照的です。
したがって、論理的には、クラスター化されたインデックス (または Oracle では「インデックス構成テーブル」)はデータですが、並べ替えられています。物理的には、B ツリーのリーフ ノードには、テーブルのすべてのデータが並べ替えられた順序で含まれています。これは、日付範囲などの連続した範囲でテーブル内のデータをスキャンする場合に非常に役立ちます。
(少なくとも SQL Server では) クラスター化インデックスに関するもう 1 つの重要な点は、クラスター化列 (つまり、クラスター化インデックスの並べ替え方法を構成する列) が、テーブルに定義する各非クラスター化インデックスの末尾に含まれていることです。これにより、クラスタリング列の検索が非常に高速になり、OLAP データベースではこれが非常に望ましいことがよくあります。
非クラスター化インデックス
テーブルは 1 つの物理的な順序でのみ保存できます。ただし、場合によっては、他の方法でデータを検索する必要があります。これらのシナリオでは、非クラスター化インデックスを使用します。これも B ツリーとして実装されますが、クラスター化インデックスのように、テーブルのデータの順序には影響しません。つまり、非クラスター化インデックスに含まれていないテーブルのデータが必要な場合、SQL Server は必要なものを取得するためにテーブル内のデータを物理的に検索する必要があります。これは別の操作であり、多くのクエリではコストがかかる可能性があり、テーブルを最適化する際の重要な設計上の考慮事項です。
単語
あなたはこのことについて本を書くことができます. 多くの人が持っています。まだ飽き飽きしていないという方は、ウィキペディアのB-Treeページをご覧ください。そこから始めましょう。それでも (本当に) 興味がある場合は、単純な B ツリーを実際にプログラミングして、何が関係しているかを確認することをお勧めします。また、SQL Server がこれらすべてを正確に格納する方法についてさらに詳しく知りたい場合は、Kalen Delaney のInside SQL Server: The Storage Engineを参照してください。この学習はすべてやり過ぎですか?それはあなたが決めることです。しかし、これを学べば学ぶほど、DB 開発に慣れ、システムが高速になります。約束します。
これは、クラスター化されたインデックスが、テーブル内のレコードが実際に格納される物理的な順序を決定したことを意味します。非クラスター化インデックスは、クラスター化/物理的な順序付け以外の順序での高速検索を可能にする、個別に格納されたキー値の単なるリストです。
簡単な例: ID
(主キー)、FirstName
、LastName
およびCar
3 人の人物を含むテーブル: 0=The Stig (Llana)、1=Jeremy Clarkson (DB9)、2=Richard Hammond (911)、3=James May (Lambo)、およびクラスター化インデックスをオンにLastName
し、非クラスター化インデックスをオンにCar
すると、実際のデータ行がテーブルに次の物理的な順序でディスクに格納されます。
ID FirstName LastName Car
1 Jeremy Clarkson DB9
2 Richard Hammond 911
3 James May Lambo
0 The Stig Llana
非クラスター化インデックスには、次のようなものも格納されます。
Car ID
911 2
DB9 1
Lambo 3
Llana 0
これは、テーブルがクラスター化インデックスの指定どおりに並べられていることを意味します。非クラスター化インデックスは、物理的に個別に格納されます。
プライマリ インデックスは技術的には "クラスター化された" インデックスではありませんが、どちらもデータに対して物理的な並べ替え順序を発生させます。違いは名前そのものに明らかです。プライマリ インデックスは、プライマリ キーを扱います。つまり、各主キーは一意である必要があります (そうでない場合、主キーにはなりません)。クラスタリング インデックスは、主キー以外のすべてのものを処理し、定義により、一意ではないことが許可される場合があります。これが「クラスター」という言葉の由来です。プライマリではないデータを並べ替える場合、それは繰り返すことができることを意味します。繰り返されるデータが一緒に表示される場合、それは「クラスター」と見なされます。