これまで非クラスター化インデックスとクラスター化インデックスを作成してきましたが，少し補足をしておきます。
目次
非クラスター化インデックスでの検索
非クラスター化インデックスは，先述の通り，インデックスファイルを辿って，終端のリープページにクラスター化インデックスのKeyが入っているので，そこからさらにクラスター化インデックスをキー参照するという2段階で検索しているというお話をしました。
ただし，今回の例では，リーフページにはインデックスである「Id」と，クラスター化インデックスのKeyである「CreateDate」が入っているという事になります。ですので，Selectする項目がもし，「Id」と「CreateDate」だけでよいという場合は，インデックスのリーフページを読むだけで完結するので，キー参照は発生せず，高速に検索することができます。
「Id」と「CreateDate」だけで10400件の検索
Select項目をIdとCreateDateだけにして次のようにSQLを実行してください。
|
1 2 3 4 5 |
DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE select ID,CreateDate from Shain where Id >= 1 and Id < 10400 |
実行プランの確認
実行プランを見ると，IndexSeekのみで，キー参照が発生していません。これはインデックスを読むだけで完結し，キー参照が発生していないという事です。
コストの確認
コストも低いことが分かります。
インデックスに無い項目を取得すると遅くなる
ただし，インデックスファイルに存在しない項目を混ぜてSelectを行うと，当然またキー参照が発生することになります。試しに「Mei」を混ぜてみましょう。
|
1 2 3 4 5 |
DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE select ID,CreateDate,Mei from Shain where Id >= 1 and Id < 10400 |
キー参照が発生し，コストも高くなっていることが分かります。
というわけで，非クラスター化インデックスのリーフページに存在する項目のみでSelectする場合は高速に取得できるという事です。
クラスター化インデックスを作成したことによる変化
クラスター化インデックスを作成したことによる変化の補足として，「テーブルスキャンが無くなる」というものがあります。これまで，全件検索などを行うと，実行プランがTableScanになっていましたよね。それが無くなります。
次のSQLで試してみましょう。
|
1 |
select * from Shain |
実行プランの確認
全件検索を行って実行プランを確認すると，ClusterdIndexScanになっています。これは，クラスター化インデックスを作成したことで，実データという概念が無くなり，クラスター化インデックスのリープページに実データがあるので，TableScanというもの自体が無くなり，クラスター化インデックスをスキャンするという行為が，これまでのテーブルスキャンと同じという事になります。なのでClusterdIndexScanとなっているという事は，クラスター化インデックスのリーフページをすべて読んだということなので，テーブルスキャンと同じと考えてください。
C#を正しい3層構造で造れてますか？
無料動画コース「C#のアーキテクチャー」（80分）をプレゼントしています
#S1_01_はじめに
#S1_02_インデックスとは
#S1_03_インデックスの有無実演
#S1_04_SQLServerのインストール
#S2_01_データベースとテーブルの作成
#S2_02_データの作成
#S2_03_全件検索
#S2_04_キャッシュとは
#S2_05_検索条件ありで検索
#S2_06_テーブルスキャンとは
#S2_07_インデックスの種類
#S2_08_非クラスター化インデックスの作成
#S2_09_非クラスター化インデックスの内部構造
#S2_10_インデックスのない列の検索とインデックスの有効化無効化
#S2_11_クラスター化インデックスの作成
#S2_12_クラスター化インデックスの内部構造
#S2_13_クラスター化インデックスの検索
#S2_14_インデックスの検索補足
#S2_15_付加列インデックス
#S2_16_プライマリキーとユニークキー
#S2_17_インデックス作成手順
#S2_18_インデックスの注意点
おわりに