インデックス

SQLServer【Index編】#S2_14_インデックスの検索補足

これまで非クラスター化インデックスとクラスター化インデックスを作成してきましたが,少し補足をしておきます。

非クラスター化インデックスでの検索

非クラスター化インデックスは,先述の通り,インデックスファイルを辿って,終端のリープページにクラスター化インデックスのKeyが入っているので,そこからさらにクラスター化インデックスをキー参照するという2段階で検索しているというお話をしました。

ただし,今回の例では,リーフページにはインデックスである「Id」と,クラスター化インデックスのKeyである「CreateDate」が入っているという事になります。ですので,Selectする項目がもし,「Id」と「CreateDate」だけでよいという場合は,インデックスのリーフページを読むだけで完結するので,キー参照は発生せず,高速に検索することができます。

「Id」と「CreateDate」だけで10400件の検索

Select項目をIdとCreateDateだけにして次のようにSQLを実行してください。

実行プランの確認

実行プランを見ると,IndexSeekのみで,キー参照が発生していません。これはインデックスを読むだけで完結し,キー参照が発生していないという事です。

コストの確認

コストも低いことが分かります。

インデックスに無い項目を取得すると遅くなる

ただし,インデックスファイルに存在しない項目を混ぜてSelectを行うと,当然またキー参照が発生することになります。試しに「Mei」を混ぜてみましょう。

キー参照が発生し,コストも高くなっていることが分かります。

というわけで,非クラスター化インデックスのリーフページに存在する項目のみでSelectする場合は高速に取得できるという事です。

クラスター化インデックスを作成したことによる変化

クラスター化インデックスを作成したことによる変化の補足として,「テーブルスキャンが無くなる」というものがあります。これまで,全件検索などを行うと,実行プランがTableScanになっていましたよね。それが無くなります。

次のSQLで試してみましょう。

実行プランの確認

全件検索を行って実行プランを確認すると,ClusterdIndexScanになっています。これは,クラスター化インデックスを作成したことで,実データという概念が無くなり,クラスター化インデックスのリープページに実データがあるので,TableScanというもの自体が無くなり,クラスター化インデックスをスキャンするという行為が,これまでのテーブルスキャンと同じという事になります。なのでClusterdIndexScanとなっているという事は,クラスター化インデックスのリーフページをすべて読んだということなので,テーブルスキャンと同じと考えてください。

SQLServerインデックスを理解して検索を高速にする方法