SAP SQL Anywhere のクラスタードインデックスについて

この記事のオリジナルは、Glenn Paulley が sybase.com に2010年9月に掲載したものです。Glenn はこの中で、オプティマイザがどのようにクラスタードインデックスを利用するのか説明するとともに、クラスタードインデックスに関連する統計情報についても解説しています。この情報を理解することで、declareされたクラスタードインデックスが効果的に使用されているのか、またインデックスを再構築した方が良いのか判断するのに役立ちます。

===

SQL Anywhereはバージョン8.0.2以来、クラスタードインデックスをサポートしてきました。SQL Anywhereにおいて、クラスタードインデックスと非クラスタードインデックスの間に物理的な違いはありません。また、参照整合性制約のメンテナンスのために暗黙的に作成されるインデックスなども含め、すべてのインデックスはクラスタ化することができます。さらに、ALTER INDEX文を使うことで、クラスタ化の属性を追加または削除できます。ただ、このクラスタ化はあくまで検索の”手がかり”であり、クエリがORDER BY句を含む場合はやはりソート処理が必要です。

インデックスがクラスタ化されている場合（ちなみに宣言できるクラスタードインデックスの数は1つのテーブルにつき1つまでです）、ローが最初に挿入される際、データベースサーバは、テーブルページ内のローの物理的並び順を、クラスタードインデックスにおけるインデックスエントリの並び順にできるだけ一致させようとします。このようなクラスタードインデックスの利点は言うまでもなく、サーバがレンジスキャンの際にクラスタ化されたこの性質を活用できることです。クエリ処理時にクラスタードインデックスによる検索を行うと、読み込まなければならないテーブルページの数を最小限に抑えることができます。

クラスタ化に関する統計情報

SQL Anywhereバージョン10からは、インデックスがCLUSTEREDとして宣言されているかどうかに関係なく、データベース内の各インデックスのクラスタ化に関する統計がサーバによって管理されるようになりました。こうした統計情報はSYS.SYSPHYSIDXシステムビューで見ることができ、また次のようなクエリを使って検索できます。

（続きは、2010年に翔泳社 CodeZine に掲載された翻訳記事をご覧ください。）

SAPのSAP SQL Anywhere製品ページはこちら