索引のチューニング・テクニックを一挙公開：DB2チューニング・ベストプラクティス（3）（1/2 ページ）

索引の作成

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　「設計アドバイザー」のおかげで、索引を設計する負担が大幅に減りました。「設計アドバイザー」は、特定のSQLワークロード（つまりSQLステートメントの集まり）に対して索引を推奨したり評価したりするために使われます。これについては、第6回で説明します。

　それでもなお、索引に関して注意すべき点がいくつかあります。

• 照会が妥当な時間内に完了している場合は、索引を追加しないでください。索引を追加すると、更新操作に時間がかかるようになり、余分なスペースが消費されるようになるからです。代わりに、1つの大きな索引を作成することで、複数の照会に対応できる場合があります。
  
  
• カーディナリティの高い列は、索引に適しています。
  
  
• 管理上のオーバーヘッドが増えるため、1つの索引の中で6個以上の列を使用することは避けてください。
  
  
• 複数列の索引については、照会の中で最も多く参照される列を、定義の中で先頭に指定します。
  
  
• 既存の索引とよく似た索引を追加することは避けてください。オプティマイザの作業が増え、更新操作の速度も低下するからです。代わりに、追加の列を含むように既存の索引を変更します。例えば、ある表の列（c1、c2）に対してすでに索引「i1」が存在しているとします。ここで、ある照会の中で「where c2=?」が使われていることに気が付いた場合、列（c2）に対して追加の索引「i2」を作成したいと思うかもしれません。しかし、このようによく似た索引を作成することは、あまり意味がありません。この索引はi1に対して冗長であり、オーバーヘッドが増えることになるからです。
  
  
• 表が読み取り専用であり、多くの行を含んでいる場合は、CREATE INDEXのINCLUDE文節を使用して、照会の中で参照されるすべての列を含む索引を定義してみてください（INCLUDEで指定する列は索引には含まれませんが、余分なデータのFETCHをなくすために、索引ページの一部として格納されます）。

クラスタ索引

　クラスタ索引を作成すると、表の中の行を、希望する結果セットと同じ物理順序で並べることができます。クラスタ索引は、CREATE INDEXステートメントのCLUSTERオプションを使って作成します。揮発性表に対してクラスタ索引を作成してはいけません。その索引が使われることはないからです。最適なパフォーマンスのためには、小さなデータ型（integerやchar(10)など）、ユニーク列、および範囲検索で最も多く使われる列に対して索引を作成します。

　クラスタ索引は、データ・ページに対するより直線的なパターンのアクセスとより効率的なプリフェッチを可能にし、ソートの必要性を減らします。つまり、挿入（INSERT）にかかる時間は長くなりますが、選択（SELECT）にかかる時間は短くなります。クラスタ索引を使用する場合は、多くの挿入を行えるように、データ・ページおよび索引ページのフリー・スペースを（PCTFREEのデフォルト値の「10」の代わりに）「15〜35」程度に増やしてください。大量の挿入が行われる表については、単一次元のMDC表（Multidimensional Clustering Table：マルチディメンション・クラスター化表）の使用を検討してください（おそらく、ID列/1000やINT(date)/100などの生成列を使用することになるでしょう）。これにより、行に対する索引ではなく（ディメンションに対する）ブロック索引が作成されます。作成される索引は小さくなり、挿入時のログの競合が大幅に減ります。

CREATE INDEXのオプション

　読み取り専用表に対する索引の場合は、PCTFREEを「0」に設定します。そのほかの場合は、使用可能なスペースを用意して挿入を高速化するために、PCTFREEを「10」に設定します。クラスタ索引を持つ表の場合は、クラスタ索引が細かくフラグメント化されないようにするために、この値をさらに大きくします。大量の挿入を行う場合は、「15〜35」程度の値が適切です。

　索引の両方向スキャンを可能にするには、ALLOW REVERSE SCANSを使用します。これにより、結果セットの昇順および降順の素早い検索が可能になります。この機能をサポートするために内部的な索引構造が変更されることはないため、パフォーマンスに関する悪影響はありません。

　INCLUDEを使用すると、索引付きでない列も索引ページ内に含めることができます。これにより、索引のみのアクセスが可能になり、データ・ページをフェッチせずに済みます。

　UNIQUEを使用すると、列（または列の集まり）の固有性を効率的に強制できます。

　タイプ2索引は、ネクスト・キー・ロッキング（next-key locking）を大幅に削減し、デフォルトの255bytesより大きな索引列の使用を可能にします。また、オンラインREORGとRUNSTATSの両方を可能にし、新しい多次元クラスタリング機能をサポートします。V8では（移行前の）タイプ1索引が表にすでに定義されている場合を除いて、新しい索引はすべてタイプ2索引として作成されます。タイプ1索引からタイプ2索引に変換するには、REORG INDEXESを使います。（次ページに続く）