管理の手引き


索引、索引の拡張、または索引の指定の作成

索引は、行の位置のリストを、 指定した 1 つまたは複数の列の内容によって分類したものです。 索引は、通常、表へのアクセスを高速にするために使用されます。 しかし索引は、論理データ設計の点でも役立ちます。 たとえば、固有索引 を使うと、 列に重複値を入力できなくなるため、表内に同じ行ができることはありません。 また、列の値を昇順にするか降順にするかを指定するためにも、 索引を作成することができます。

索引の拡張とは、 構造型または特殊タイプの列の索引と一緒に使用される索引オブジェクトです。

索引の指定はメタデータ構成です。 それは、ニックネームが参照するデータ・ソース・オブジェクト (表または視点) の索引があることを、 最適化プログラムに通知します。 索引の指定は行位置のリストを含んでおらず、索引を記述したものにすぎません。 最適化プログラムは索引の指定を使用して、 ニックネームが参照するオブジェクトへのアクセスを向上させます。 ニックネームが初めて作成される場合、 DB2 が認識できる形式の基礎表用の索引がデータ・ソースにあれば、 索引の指定が生成されます。
注:視点が 1 つの表に対するものであれば、 必要に応じて表のニックネームや視点のニックネームに対する索引の指定を作成します。

次の場合は、索引または索引の指定を手動で作成します。

索引の指定は、基礎表の索引が存在しない場合に作成できます (DB2 は、 CREATE INDEX ステートメントの発行時にリモート索引があるかどうかを調べません)。 また、UNIQUE キーワードを指定したときでも行を固有のものにする必要はありません。

DB2 索引アドバイザーは、最適の索引セットを選ぶのに役立つウィザードです。 このウィザードは、コントロール・センターからアクセスできるウィザードです。 互換性のあるユーティリティーとして、db2advis があります。

索引は、列ごとに基礎表の中に定義されます。 索引は、表の作成者、 または特定の列では直接アクセスが必要であることについて知っているユーザーが作成できます。 1 次索引キーは、ユーザー定義の索引がすでに存在しているのでない限り、 基本キーに対して自動的に作成されます。

1 つの基礎表に対して、索引はいくつでも作成でき、 そのようにして照会のパフォーマンスを高めることができます。 しかし、索引の数が多ければ多いほど、 更新、削除、挿入の操作時にデータベース・マネージャーの実行する修正作業は多くなります。 更新事項の多い表に対してたくさんの索引を作成すると、 要求の処理が遅くなってしまう可能性があります。 したがって、索引の使用は、 頻繁にアクセスするための利点があるということが明らかな場合だけにしてください。

索引キーの一部となる列はどれも、255 バイトまでに制限されています。 1 つの索引あたりの列の最大数は 16 です。 タイプ付き表の索引を作成する場合、 列の最大数は 15 です。 索引キーの最大長は 1024 バイトです。 前述のように、 1 つの表に対する索引キーが多くなると、要求の処理速度が低下することがあります。 同様に、索引キーが大きくなっても、 要求の処理速度が低下することがあります。

索引キー は 1 つの列または複数の列の集合のことであり、 そこに索引が定義され、索引の有効性が判別されます。 索引キーを構成する列の順序は、索引キーの作成に影響を与えることはありませんが、 索引を使用するかどうかを決定するときに、最適化プログラムに影響を与えます。

索引を作成する表が空であっても、索引は作成されますが、 表がロードされるか行が挿入される時点まで索引項目は作成されません。 表が空でない場合、CREATE INDEX ステートメントの処理中に索引項目が作成されます。

クラスター化索引 では、 新しい行がキー値の近い既存の行と物理的に近い位置に挿入されます。 このことによって、データ・ページへのアクセス・パターンの線形化が進み、 プリフェッチの効果性が上がるので、照会の間のパフォーマンスが向上します。

基本キーをクラスター化索引にしたい場合は、 CREATE TABLE で基本キーを指定しないでください。 基本キーが作成されると、関連する索引を変更することはできなくなります。 基本キー文節を指定しないで CREATE TABLE を実行します。 その後、クラスター化属性を指定して CREATE INDEX を発行します。 最後に、ALTER TABLE ステートメントを使用して、 作成されたばかりの索引に対応する基本キーを追加します。 この索引が、基本キー索引として使用されます。

一般的に、クラスター化索引が一意的なものであれば、 クラスター化の保守はより効果的に行えます。

固有索引キーの一部ではないものの、その索引で保管され保守される列データは、 組み込み 列と呼ばれます。 組み込み列を指定できるのは、固有索引についてだけです。 組み込み列のある索引を作成しているときは、固有キー列だけが保管され、 固有なものであると見なされます。 組み込み列を使用すると、索引へのアクセスが関係しているときには、 データ検索のパフォーマンスが向上します。

データベース・マネージャーは、 最下レベルが葉ノードで構成される場合の索引の保管に B+ 木構造を使用します。 葉ノードや葉ページとは、実際の索引キー値が保管される場所です。 索引の作成時には、上記の索引葉ページを使用可能にしてオンラインでマージしたり、 再編成することができます。 オンラインでの索引の再編成は、大幅な削除および更新活動の後、 多数の索引葉ページにわずかの索引キーだけが残されるという状況を避けるために使用します。 そのような状況でオンライン再編成を行わなければ、 データと索引のオフライン再編成によってスペースを再利用できるだけです。 作成する索引に、 索引ページをオンラインで再編成する機能が必要かどうかを判断するには、 次の質問を考慮してください。すなわち、 キーを削除するたびにマージ可能なスペースの有無を検査するという追加のパフォーマンス上の費用、 および (スペースが十分にある場合に) マージを完了するための実費用とを費やすことは、 索引用スペースの使用効率の改善という利点に勝るか、 またスペースを再利用するためにオフラインで再編成を実行するという、 必要性の小さい作業に見合う価値があるか、ということです。
注:オンライン再編成によるマージ後に解放されたページは、 同じ表内の他の索引に再利用することだけに使用できます。 全再編成を使用すると、 解放されたページを他のオブジェクト (データベース管理記憶域での作業時)、 またはディスク・スペース (システム管理記憶域での作業時) に使用できます。 また、オンライン再編成では、索引の非葉ページは解放されませんが、 全再編成では、索引を可能な限り最小化して索引を最小化することにより、 非葉ページと葉ページに加えて索引のレベル数も削減されます。

オンラインで再編成する索引を実現させる方法についての詳細は、 CREATE INDEX ステートメントの使用を参照してください。

1 つの区分データベース内の表に対する索引は、 同じ CREATE INDEX ステートメントを使用して作成されます。 これらの索引は、その表の区分化キーに基づいて区分化されます。 表上の索引は、ノード・グループ内の各ノード上のその表内のローカル索引から作られます。 複数区画環境で定義された固有索引は、 区分化キーのスーパーセットでなければならないことに注意してください。

パフォーマンス上のヒント: 以下の一連の作業を実行しようとしている場合には、 LOAD ユーティリティーを使用する前に索引を作成してください。

作業の実行順序を、以下のようにすることを考慮する必要があります。

  1. 表を作成する
  2. 索引を作成する
  3. statistics yes オプションを要求して表をロードする

LOAD のパフォーマンス向上について詳しくは、 システム・カタログ表を参照してください。

索引作成後も、索引は常に維持されていきます。 その結果、アプリケーション・プログラムが、 表の中の行をランダムにアクセスおよび処理するためにキー値を使用したときに、 そのキー値に基づく索引を使用して、行を直接アクセスすることができます。 基礎表の中の行の物理的な記憶域が順番に並んでいるわけではないので、このことは重要です。 行を挿入すると、クラスター化索引の定義をしなければ、 その行が単に最も便利な記憶場所に入れられるだけです。 特定の選択条件に一致する表の行を探索しているときで、表に索引がない場合、 表全体が走査されます。 索引を使用すれば、時間のかかる順次探索を実行することなく、データ検索を効率的に行えます。

索引のデータは、表データと同じ表スペース内か、 または索引データが入った別個の表スペース内に保管することができます。 索引データの保管に使用する表スペースは、 表の作成時に決められます (複数の表スペースへの表の作成を参照してください)。

コントロール・センターを使用して索引を作成するには、以下のようにします。
  1. オブジェクト・ツリーを順に展開し、 「索引 (Indexes)」フォルダーを表示します。
  2. 「索引 (Indexes)」フォルダーを右クリックして、 ポップアップ・メニューから「作成 (Create)」-->「ウィザードを使用して索引を (Index Using Wizard)」を選択します。
  3. このウィザードのステップに従って、タスクをすべて実行します。

コマンド行を使用して索引を作成するには、以下のように入力します。

   CREATE INDEX <name> ON <table_name> (<column_name>)

索引の作成については、 次の 索引の使用CREATE INDEX ステートメントの使用の 2 つの部分でさらに詳しく説明します。

索引の使用

索引がアプリケーション・プログラムによって直接使用されることはありません。 索引を使用するかどうか、および使用できる可能性がある索引はどれかを判断するのは、 最適化プログラムの仕事です。

表上での最適な索引は、以下のものです。

索引の利点に関する詳しい説明については、 索引走査の概念を参照してください。

CREATE INDEX ステートメントの使用

重複値の許容される索引 (非固有索引) を作成することができます。 それによって、基本キー以外の列による効率的な検索が可能になり、 索引列に重複値を入れることができるようになります。

以下の SQL ステートメントは、EMPLOYEE 表の LASTNAME 列を昇順にソートしたものから、 LNAME という非固有索引を作成します。

   CREATE INDEX LNAME ON EMPLOYEE (LASTNAME ASC)

次の SQL ステートメントは、電話番号列に基づく固有索引を作成するものです。

   CREATE UNIQUE INDEX PH ON EMPLOYEE (PHONENO DESC)

固有索引を使う場合は、索引列に重複値を入れることができなくなります。 行を更新するかまたは新しい行を挿入する SQL ステートメントの終わりに、制約が施行されます。 1 つ以上の列のセットがすでに重複値をもっている場合には、 このタイプの索引は作成できません。

ASC というキーワードは、索引項目を列ごとの昇順にします。 また、DESC は、列ごとに降順にします。 省略時は昇順です。

構造型を処理する際、構造型がユーザー定義索引タイプの作成に必要になることがあります。 その場合は、索引の保守、索引の検索、および索引活用機能を定義する手段が必要になります。 索引タイプの作成要件についての詳細は、SQL 解説書 を参照してください。

次の SQL ステートメントは、 EMPLOYEE 表の LASTNAME 列に INDEX1 というクラスター化索引を作成するものです。

CREATE INDEX INDEX1 ON EMPLOYEE (LASTNAME) CLUSTER

効果性を高めるには、 ALTER TABLE ステートメントの PCTFREE パラメーターでクラスター索引を使用します。 このようにすると、新しいデータは新しいページに挿入されるため、 クラスター化の順序が崩れることがありません。 通常、表に対する INSERT アクティビティーが多ければ多いほど、 クラスター化を保守するために必要な (その表での) PCTFREE 値は大きくなります。 この索引は、データが物理ページに置かれる順序を決定するので、 特定の表について定義できるクラスター化索引は 1 つのみです。

一方、これらの新しい行の索引キー値が、たとえば常に高いキー値である場合は、 表のクラスター化属性はそのキー値を表の最後に置こうとします。 他のページに空きスペースがあっても、 クラスター化を保つことについてはほとんど意味がありません。 この場合、表を追加モードにすることは、 クラスター化索引および PCTFREE 値を大きくするという方法よりもよい方法です。 ALTER TABLE APPEND ON を出して、表を追加モードにすることができます。 ALTER TABLE に関する概説については、表属性の変更を参照してください。 ALTER TABLE に関する詳細については、SQL 解説書 を参照してください。

上記の事柄は、UPDATE によって生成される、 行のサイズを増加させる新しい「オーバーフロー」行についても当てはまります。

CREATE INDEX ステートメントの MINPCTUSED 文節は、 索引葉ページ上で使用される最小スペースの限界値を指定します。 この文節が使用されると、この索引用にオンラインの索引再編成が使用可能になります。 それが使用可能になったら、 以下の考慮事項を使用して、オンライン再編成を行うかどうかを決定します。 すなわち、この索引の葉ページからキーが削除され、 ページ上の使用済みスペースのパーセンテージが指定限界値を下回ったら、 近隣の索引葉ページを調べて、 2 つの葉ページ上のキーを単一の索引葉ページにマージできるかどうかを判別します。

たとえば、次の SQL ステートメントは、オンライン索引再編成が使用可能な索引を作成します。

   CREATE INDEX LASTN ON EMPLOYEE (LASTNAME) MINPCTUSED=20

この索引からキーが削除されるとき、 索引ページに残っているキーが索引ページの 20 パーセント以下を占めていれば、 この索引ページのキーと近隣の索引ページのキーをマージして索引ページを削除しようとします。 結合したキーが単一ページにすべて収まる場合、 このマージは実行され、索引ページの 1 つが削除されます。

CREATE INDEX ステートメント PCTFREE 文節は、 索引が作成されるときに空きスペースとして残す各索引ページのパーセンテージを指定します。 索引ページに多くの空きスペースを残すと、分割されるページが少なくなります。 このようにすると、順次索引ページを回復するために表を再編成する必要性が少なくなりますが、 この必要性はプリフェッチを増大させるものです。 プリフェッチは、パフォーマンスを向上させる 1 つの重要な構成要素です。 また、キー値が常に高い場合は、 CREATE INDEX ステートメントの PCTFREE 文節の値を低くすることを考慮したいでしょう。 そうすることにより、各索引ページ上で予約されるむだなスペースは限られたものになります。

複数区分データベースでは、固有索引を区分化キーのスーパーセットとして定義しなければなりません。

複製要約表がある場合は、その基礎表 (複数も可) には固有索引がなければならず、 複製要約表を定義する照会で索引キー列が使用される必要があります。 詳しくは、複製要約表を参照してください。

区画内並行化の場合、索引作成のパフォーマンスは、 索引作成の間に実行されるスキャンとソートに複数のプロセッサーを使用することによって向上します。 複数プロセッサーの使用は、 intra_parallel を YES(1) または ANY(-1) に設定することによって可能になります。 索引作成の間に使用されるプロセッサーの数はシステムによって決定され、 構成パラメーターの dft_degree または max_querydegree、 アプリケーションの実行時の程度、 または SQL ステートメントのコンパイルの程度によって影響を受けることはありません。 データベース構成パラメーターの index sort が NO である場合、索引作成は複数のプロセッサーを使用しません。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]