私はクラスタ化インデックスはBツリーを作成し、実際のデータはリーフの二重リンクリストとして接続されて格納されていることを理解します。SQL Serverのクラスタード・インデックス・スキャン中に実際の表データを読み取るか、または索引ポインターだけを読み取っていますか？
しかし、インデックス・スキャン（任意の「ここ」句を使用せずにテーブルからデータを選択するが）がある場合、SQLサーバが唯一のインデックスポインタ（非リーフノード）を読んでないか、それが実際にデータを読み込むん。
私の実行計画は、クラスタ化インデックス・スキャンは、私のテーブルサイズとほぼ同じである1 GBのデータを、得たことを示しています。私の理解によると、SQLインデックススキャンは、すべての実際のテーブルデータを取得する必要があります。私はここで何かを逃していますか
クラスタ化インデックス自体はテーブルなので、テーブルがread..Indexポインタは、ちょうどあなたが直接テーブルを作成する場合は、インデックス自体が...
実際のテーブルでクラスタ化されたB木
をナビゲートするために使用されていますクラスタード・インデックスを持たないヒープと呼ばれます。これは未整理の（順序付けられていない）一連のページです。各ページは、前のページと次のページ（二重にリンクされたリスト）を指しています。
今、あなたがそのテーブルのためのクラスタ化インデックスを作成する想像：
すべてのページは現在、クラスタ用に指定されたキーの順序で格納されている - >これらは、リーフ・レベルのページで、すべての行の実際のデータが含まれています。これらは引き続き二重リンクリストを使用します。彼らはバランスの取れたツリーを形成するように
また、クラスタ化インデックスの構造は、上位レベルでの余分なページを伴います（複数のレベルである可能性があり） - >これらは分岐ページとルートページです。クラスター化されたキーから派生したデータは、下位レベルのページへのポインターとして使用されます。
この形成は、その結果、SQLエンジンは、（呼び出さシーク）は、例えば、容易にデータを見つけるために必要なページを見つけることができていますクラスタキーと一致する述語を使用するクエリを実行すると、正確なデータを効率的に見つけることができます。
キーが一致するか、またはSQLがそのテーブルを知っていれば十分に小さい（または、それがほぼ全テーブルのデータを返している知っている場合でも）、それは上位レベルのページを使用する必要はありませんしていない場合。リーフレベルのページに直接移動して、すべての行をスキャンし、一致するレコードを見つけることができます。前と次のページを指すように二重リンクリストを覚えておいてください。
ボーナス：それは求めまたはSQLは、それが求めるよりも、スキャンする方が効率的だと思ったを使用することができなかったので、あなたはWHERE句を指定した場合にもインデックススキャンがある可能性があります。
これが役立つかどうか教えてください。