EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

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

  2011/07/28 07:00

あっというまに今年も後半に突入してしまいました。このところ毎日結構暑くなってきて、電力が心配になってきましたが、みなさん節電されていることと思います、無茶して体をこわさない程度にしましょう。無駄を省いて効率よくリソースを使いましょうというところでは、エアコンもデータベースも同じですね。エアコンの節電のコツは、設定温度を下げすぎないこと、室外機の置き場に注意すること、自動運転にすること、フィルターを掃除すること、古いエアコンは買い換えることなどだそうです。データベースに置き換えると、無駄にパワーを使うクエリを使用しないこと、物理設計に注意すること、自動チューニングにまかせること、モニタリングとメンテナンスすること、新しいバージョンを使うことということでしょうか?

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

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

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

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

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

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

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

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 多田典史(タダヨリヒト)

    日本マイクロソフト株式会社 SQL Server カスタマー アドバイザリー チーム プリンシパルプログラムマネージャー SQL Serverとの関わりは日本マイクロソフトに入社した当時のSQL Server 7.0の発売以前から。マイクロソフトコンサルティングサービスに所属していたときにはBI系のプロジェクトに主に携わる。その後SQLCATに異動して現在は東京在勤で日本のお客様、パートナー様を担当している。

バックナンバー

連載:正しく使えば速くなる!多田が教えるSQL Server最適化のオキテ
All contents copyright © 2007-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5