これまで非クラスター化インデックスとクラスター化インデックスを作成してきましたが,少し補足をしておきます。
目次
非クラスター化インデックスでの検索
非クラスター化インデックスは,先述の通り,インデックスファイルを辿って,終端のリープページにクラスター化インデックスの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となっているという事は,クラスター化インデックスのリーフページをすべて読んだということなので,テーブルスキャンと同じと考えてください。
■4700人以上が受講している動画コースはこちらからご確認ください
#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_インデックスの注意点
おわりに
■4700人以上が受講している動画コースはこちらからご確認ください