検索
連載

SQL Serverのインデックス構造(前編)SQL Server 2000 チューニング全工程(4)(2/2 ページ)

本連載ではSQL Server 2000のチューニングに関するノウハウを解説する。SQL Server 2000は自動チューニング機能を持つために、チューニングはあまり必要ないと思われがちだが、そのアーキテクチャを理解し適切にツール類を使用しなければ、本来のパフォーマンスを得られない。(編集局)

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

インデックスの種類は2つ

 SQL Serverのテーブルに定義できるBツリー・インデックスの種類には、クラスタ化インデックスと非クラスタ化インデックスと呼ばれる2種類があります。これらには以下の相違点があります。

クラスタ化インデックス 非クラスタ化インデックス
テーブルに作成できる数 1個 249個まで
リーフノード インデックス付けされた列の値に基づきソートされたデータ行が格納される インデックス付けされた列のデータ行へのポインタ(行識別子:RID)が格納される
表1 Bツリー・インデックスの種類と相違点

 図2で示したインデックスの構造は、リーフノードにアルファベット順に並べ替えられたデータ行が格納されているため、クラスタ化インデックスとなります。データ行の並べ替えは、1カ所(1つの列、または複数の列のセット=複合インデックス)でしか行えないため、クラスタ化インデックスは、テーブルに1個だけに限定されます。また、インデックスには、キー値が格納されるため、キー値のサイズをなるべく小さく保つことで、インデックスページの数を減らすことができ、より高速な検索が可能になります。

 クラスタ化インデックスが作成されていないテーブルのことをヒープと呼びます。非クラスタ化インデックスは、すでにクラスタ化インデックスが作成されているテーブルに追加される場合とヒープ状態のテーブルに作成される場合とがあります。テーブルに両方の種類のインデックスを作成する場合は、クラスタ化インデックスの作成により、データ行の物理的な並べ替えが発生するため、非クラスタ化インデックスを作成する前に、クラスタ化インデックスを作成するようにします。

 図4は、ヒープに非クラスタ化インデックスを作成した場合のデータ行へのアクセスを示しています。クラスタ化インデックスの場合は、辞書や電話帳と同様に、検索対象となるデータ行はソートされていますが、非クラスタ化インデックスは、書籍の索引のように、リーフノードはソートされた状態のキー値と検索対象となるデータ行へのポインタを保持しています。このポインタは行識別子(RID)と呼ばれ「データ・ファイル番号:ページ番号:行番号」で構成されています。リーフノードには、キー値とポインタしか保持していないため、1個のテーブルに複数作成することができます。

図4 非クラスタ化インデックスによるヒープ内のデータ行の検索 (クリックで拡大します)
図4 非クラスタ化インデックスによるヒープ内のデータ行の検索
(クリックで拡大します)

 なお、リーフノードに格納されているデータ行へのポインタ情報(行識別子:RID)を基に実際のデータ行を読み込む内部操作のことはBookMark Lookupと呼ばれています。図4では、非クラスタ化インデックスの検索(Index Seek)により180番のページに検索対象(姓 = 'Aida')のデータ行が2行あることを見つけ出していますが、この後、2行に対して(4)と(5)の矢印で、BookMark Lookupを行っていることを示しています。BookMark Lookupは検索対象のキー範囲の件数分だけデータ・ページへのランダム・アクセスとして処理されます。従って、BETWEEN句を使用した範囲検索などでは、多くのページIOが発生する可能性もあります。


 次回は、クラスタ化インデックスが作成されたテーブルに、非クラスタ化インデックスを作成する場合などインデックスの構造に関する残りの部分と、実際にインデックスを作成する際の考慮事項を説明していきます。(次回に続く)


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る