索引

  索引の効能



なんといっても、検索速度 を高める為にあります。RDB では、検索条件に使用する列に索引がなければ、全件読み出しになるため、数百件では解りませんが、数万、数十万件のオーダーになるとはっきりその違いが現れます。ですから、システムに必要な条件には、索引を追加する事が通常となりますが、むやみに追加すると行の追加や索引のある列の更新時に索引自体の更新も行なわれる為、デメリットもある事にはあります。

しかし、余程無茶な事をしないかぎり1行の更新に対するオペレータの体感速度はそうそう落ちるものではありません。とにかく、索引をつけただけで10秒かかっていたものが、1秒以内でおさまるのは良くある事です。うまく使うのが当然と言えます



  索引作成時のガイドライン



データ量が多くなればなる程、索引を付ける事は必然となります。システムで検索処理を行なう場合、オペレータが必要、と言うよりは、扱える数というのは100件程です。データが1万件あるとすれば、既にその100件は1%です。Oracle 推奨は 2〜4%ですから、検索処理では、殆どの場合必要となります。

それから、次に重要なのはテーブルの結合に使用する列です。通常、正規化の行なわれたテーブルは結合無しでは成り立ちません。主キー以外でも結合を想定する列は良く現れます。そのような場合も、(件数を考慮しますが) 索引を付ける理由になります。



  作成構文

索引の作成構文はいたってシンプルです

  
create index 索引名
	on 表名 (列名リスト)
  

create と index の間に unique または bitmap を指定できます。
unique はその名の通り一意索引ですが、通常は「制約」で指定したほうが管理しやすいと思います。
何故かというと、オブジェクトとしての索引は、検索速度向上が目的であり、一意である理由は殆どあり
ません。一意である理由はシステム的な理由になり、表の属性として考えたほうが良いからです



  索引の種類

Oracle の索引作成構文的には以下の5つとなります

------------------------------------------------
1) 通常索引 (B ツリー索引)
2) ビットマップ索引
3) パーティション索引
4) ファンクション索引
5) ドメイン索引
------------------------------------------------

このうち、パーティション索引と、ドメイン索引はとりあえず忘れてても良いと思います。特に重要なのはビットマップ索引です。また、パフォーマンスの機能性を補足する索引体系としては、以下の6つとなります

------------------------------------------------
1) B ツリー索引
2) B ツリークラスタ索引
3) ハッシュ・クラスタ索引
4) 逆キー索引
5) ビットマップ索引
6) ビットマップ・ジョイン・インデックス
------------------------------------------------

逆キー索引は、通常索引作成時の索引属性として REVERSE を指定した時に作成されます。これは、索引列のバイトを逆にするものですが、利用目的は特殊な場合に限られます。もし作成してしまうと、キー指定フェッチまたは全索引(表)スキャンしか実行できなくなります

ファンクション索引は、調べだすと頭が痛くなるほど情報が出てきます。とりあえず、特殊な場合に必要である事に変わりは無いので、存在と簡単な作成方法(含権限等前提条件)を知っておきましょう



  ビットマップ索引

ビットマップ索引は、Oracle9i Enterprise Edition で使用可能です。

構造上の特徴は、ROWID のリストのかわりに各キー値のビットマップを使用する事です。それ以外は通常索引と同じですが、機能上の特徴は重要です

ビットマップ索引は通常の索引と同じ機能を果たしますが、異なるキー値の数が多くない場合に領域を有効に使用できます。また、WHERE 句に指定されたいくつかの条件に対応する索引を効率的にマージするので、応答時間が短縮され、多くの場合は劇的に改善されます。

ビットマップ索引は並列して更新が多く発生するシステムには不向きですが、大量のデータを検索を目的とするシステムに適しています。注意すべきは、大小の比較による問合せの対象とされる列には適しておらず、比較におけるWHERE 句に現れる列には、B ツリー索引のほうが適しています。ビットマップ化された索引は、AND、OR、NOT 問合せまたは等価問合せでのみ有効です。

ビットマップ索引の使用による最大のメリットは、カーディナリティの低い列、つまり表内の行数に比べて個別値の数が少ない列において、最も大きくなります。値の繰返しが少なく、カーディナリティが高い列でも、その列が問合せのWHERE 句で複雑な条件に含まれることが頻繁にある場合は、ビットマップ索引の候補になります。



  再構築

マニュアルでは、案外あっさりです

索引を再作成するときは、既存の索引をデータソースとして使用でき、記憶特性の変更や新しい表領域への移動ができます。既存のデータソースに基づいて索引を再作成すると、ブロック内の断片化も解消され、索引を削除してCREATE INDEX 文を使用するよりも、パフォーマンスは優れています

次の文は、既存の索引emp_name を再作成します。
ALTER INDEX emp_name REBUILD

索引はオンラインで再作成できます。次の文は、emp_name 索引をオンラインで再作成します。
ALTER INDEX emp_name REBUILD ONLINE










  infoboard   管理者用   
このエントリーをはてなブックマークに追加





フリーフォントWEBサービス
SQLの窓WEBサービス

SQLの窓フリーソフト

素材

一般WEBツールリンク

SQLの窓

フリーソフト

JSライブラリ