SQL Serverの大きな特徴、クラスタ化インデックスを押さえよう！

インデックスが効いているとIOが少なくて済む

　さて、前回はパフォーマンスについての全般的なお話と、インデックスの基本的なところを試してみました。今回も続けてインデックスに注目してみたいと思います。前回試してみた結果を誤解を恐れずにまとめると、「インデックスが効いているとIOが少なくてすむ」「IOが少ない方が速い」ということです。

　実は結構いろいろなことをすっ飛ばしましたので補足させてください。

　リレーショナルデータベース中のデータはテーブルに入っており、テーブルはファイル上ではページという単位に分割されて記録されています。例で1240ページ読んだと書いていたのは、このページのことです。ある行を探したいときに、インデックスがないとテーブル上のデータを全ページを読みながら探すことになります。インデックスがついていると、まずインデックスを見て、そこにこのデータは何ページ目の何行目に入っているよと書いてあって、そのページだけ見に行けば欲しいデータが見つかります。イメージとしては1冊の本の中から特定の単語や文章を見つけたいときに、本の先頭から全ページ読んで探すのがインデックスのないパターン、索引のページを見に行って目的の単語などをみつけてページ番号を確認してからそのページを見に行くのがインデックスありのパターンです。

　インデックス自身もテーブルと同じく、データベースのファイル上では複数のページとして存在しています。インデックスのページにはインデックスのキーと行ロケータ（目的の行を示すもの、本の例ではページ番号）が入っており、Bツリーという構造になっています。このBツリーの末端のページの中の行が、実際のデータページの中の行を指しています。

インデックスのBツリー構造の図

　 詳しくはSQL Server Books Onlineの次のページ（非クラスタ化インデックスの構造）をご参照ください。