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

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

» 2005年01月18日 00時00分公開

[沖要和，NRIラーニングネットワーク]

インデックスはなぜ必要か

　インデックスはデータベースの索引というべきものです。書籍の中からある項目について調べたい場合、書籍の内容をすべて読むのではなく、索引を有効に活用して必要な情報を取り出します。データベースにおいてもデータベースに含まれるデータの場所を索引としてあらかじめ生成しておけば、データの検索が効率的に行えると期待できます。検索処理は、SELECT文によるデータの参照時に行われますが、UPDATE文やDELETE文でも変更対象のデータを見つけ出すために検索処理が行われます。

　SQL Server^注では、「ページ」と呼ばれる8Kbytesの連続したディスク領域にデータを格納します。つまり、ページがIOの最小単位になります。ページには、データ行や、インデックスに使用される情報などが格納されます。テーブルにインデックスがない場合、検索対象となるデータ行を見つけ出すために、テーブルの全データ行をメモリに読み込んで、検索条件に合ったデータ行かどうかを比較する必要があります。仮に1ページ平均40件のデータ行を格納していたとすると、テーブルに500万件のデータ行がある場合、12万5000ページ（約1Gbytes）をメモリ内に読み込むことになります。

注）本文中で特に断らない限り、SQL Serverと表記した場合はバージョン2000を指す。また、次期バージョンとなるSQL Server 2005の情報については、適宜盛り込む予定だ。

　図1では、インデックスが付けられていないテーブルを使用して、「姓」列で'Aida'の値を持つデータ行を検索しているイメージを示しています。

図1　レコードの全件検索

　このテーブルにBツリー・インデックスが付けられた場合、インデックス・ページは図2のような階層構造となります。検索で使用する列の値がソートされて格納されるため、インデックス・ページのツリーをたどって効率のよいデータ・アクセスが行えます。検索対象のデータ行が1件だけの場合、または、複数件であっても検索対象が同じデータ・ページ内にあれば、インデックス・ページの階層分のIOで、対象のデータ行を取り出せます。例えばインデックスが3階層であれば、3ページ（24Kbytes）分のデータ読み取りで済んでしまいます。

図2　インデックスによる検索（クリックで拡大します）

インデックスの構造を知る

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

　これらの違いを解説する前に、まずBツリー・インデックスの基本構造を説明しましょう。インデックスは、最上部のルートノードから始まります。このノードは、データ行の検索が行われるとき、最初にアクセスされるページです。ルートノードには、多数のインデックス行が含まれ、これらのインデックス行には下位のインデックス・ページへのポインタとなる情報（図2では下位のファイル番号とページ番号が使用されています。ちなみに、ファイル番号1は、プライマリ・データ・ファイル（*.mdf）を示します）が含まれています。最下位のノードはリーフノードと呼ばれ、中間に位置するノードは中間ノードあるいはブランチノードと呼ばれています。

　「Bツリー」という名前が示すように、中間ノードからリーフノードにかけて、上下を逆にした木のような形で広がっています。また、インデックスの中間ノードとリーフノードでは、同じレベルに位置する隣接したページ間のリンクリストを保持していることも理解しておきましょう。