articleマイクロソフトの植田です。key制約を指定してテーブル作成するとデフォルトでクラスタ化インデックスが作成される点があります。クラスタ化インデックスを作成するメリットがあるためこのような動作を行いますが、非クラスタ化インデックスのみのテーブルと比べてどれほどの性能差があるのでしょうか。今回はこの点についてテストした結果をご紹介させて頂きます。本内容は米国のTechNetのサイトにて公開されておりますが、ここでは要点をいくつかピックアップして解説したいと思います。注)本内容に関する詳細は以下のWebサイトで取り扱われております。http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/clusivsh.mspx今回の検証の主な目的は以下を明らかにすることでした。大量の行の挿入/削除を行った時、クラスタ化インデックスを持つテーブルと、非クラスタ化インデックスを持つテーブルとでは、ディスクスペースの使用率(効率性)に違いがあるか本ブログでは上記の1について説明させていただきます。クラスタ化インデックスと、非クラスタ化インデックスの大きな違いは、クラスタ化インデックスでは、インデックス・ツリーの最下層の部分(リーフノード)に実際の行のデータが収められているデータ・ページ(行データはインデックスキーの順序でソートされている)がリンクされるのに対し、非クラスタ化インデックスでは、インデックス・ツリーのリーフノードにインデックスキーが存在する行の行IDが格納されていて、実際の行データはデータ・ページ上でランダムに配置されている(インデックスキーの順序に沿って並んでいるわけではない)点です。Onlineをご参照ください。クラスタ化インデックスの構造:http://msdn2.microsoft.com/ja-jp/library/ms177443.aspx非クラスタ化インデックスの構造:http://msdn2.microsoft.com/ja-jp/library/ms177484.aspxテスト環境テストでは以下のテーブルを使用しました。DATETIME)インデックス作成時のT-SQL文は以下の通りです。TIME_KEY)テーブル、および、インデックスのサイズは以下の表のようになっています。テーブル/インデックス行数ページ数サイズ(MB)クラスタ化インデックス16,125,000181,9921,421非クラスタ化インデックス16,125,00075,708591ヒープ16,125,000181,1821,415表1:テーブル/インデックスサイズ注)ヒープとはクラスタ化インデックスが存在しないテーブルです。クラスタ化インデックスではデータ・ページがインデックスのツリー構造に含まれるためテーブルとインデックスを明確に区別していません。ハードウェア、および、ソフトウェアのテスト環境は以下の通りです。今回のテストでは以下の方法でパフォーマンスを計測しました。Performanceランダムに値を作成した1,000,000行のデータをテーブルに挿入し、単位時間当たりの平均処理速度を測定します。1回のINSERTで1行挿入するため、INSERT文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。Performanceテーブル中のランダムに選んだ1,000,000行のデータを更新し、単位時間当たりの平均処理速度を測定します。1回のUPDATEで1行更新するため、UPDATE文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。Performanceテーブル中のランダムに選んだ1,000,000行のデータを削除し、単位時間当たりの平均処理速度を測定します。1回のDELETEで1行削除するため、DELETE文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。テーブル中のランダムに選んだ1,000,000行のデータを抽出し、単位時間当たりの平均処理速度を測定します。1回のSELECTで1行選択するため、SELECT文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。テーブル中であるインデックスキーの範囲にあるデータを抽出し、その処理を1,000,000回行って単位時間当たりの平均処理速度を測定します。1回のSELECTで選択される行数は258行でした。サンプルT-SQL文は以下です。上記のDML操作を行うためのクライアントとして、ODBCライブラリを使用してデータベースにアクセスする簡単なプログラムを用意しました。テスト手順パフォーマンス計測の手順は以下の通りです。今回得られた結果は以下の通りでした。(selects/sec)587454-22.7結果の考察このようにすべてのDML操作においてクラスタ化インデックス付テーブルの方が、非クラスタ化インデックス付テーブル(ヒープ)よりもパフォーマンスが良いという結果になりました。これらの差は、WHERE句で指定された行を検索する際に、クラスタ化インデックス付テーブルの場合は、インデックスを走査してそのまま行が格納されているデータ・ページにたどり着くのに対し、ヒープでは非クラスタ化インデックスを走査して行IDを取得し、その後データ・ページへアクセスする必要があるために生じていると考えられます。4-b)において特に顕著な差が生じているのは、このテストケースにおいて、(インデックスキーの順序でデータが並んでいる)クラスタ化インデックス付テーブルの利点が最も有効に活用されているためと考えられます。通常インデックスのメンテナンスコストが懸念されるINSERT処理においても、クラスタ化インデックス付テーブルにおけるパフォーマンスがヒープにおけるパフォーマンスよりも良い、という結果になりました。その理由は、クラスタ化インデックスのメンテナンスのコストがヒープにおけるデータページアクセスのコストよりも低かったためと考えられます。両者のコストはインデックスキーに指定する列のデータサイズ等に依存し、今回の検証結果においてもわずかな差しかないことを考慮すると、環境によっては逆の結果になる可能性もあります。結論1千万行程度のテーブルにおいて、クラスタ化インデックスを作成した場合と非クラスタ化インデックスを作成した場合でDML操作のパフォーマンスにどのような違いが生じるかを検証しました。その結果、すべてのDML操作においてクラスタ化インデックス付テーブルに対するパフォーマンスが、非クラスタ化インデックス付テーブルに対するパフォーマンスを上回ることを観測しました。上記の結果は今回のテスト環境、および、テスト方法において得られたもので、他の環境やテスト方法において同様の結果が出るとは限りません。2005においてデータベースを設計する際の、基礎的なデータとして利用されることをお勧めします。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。FeedbackTrademarks。