索引構成表(IOT:Index Organized Table)
索引構成表 とは、簡単に説明するとデータ全体を最初から B-Tree インデックス に格納しているものである。表と主キーのインデックスとの共用体(⇔ C言語における構造体)になっているようなものである。
実際は B-Tree インデックスにはキーと ROWID が格納される程度なので、索引に入っているのではない。他のデータも入れることができるように拡張した表のことである。
通常であれば、表+ 主キー(インデックス)の2つのデータ領域が必要なところを索引構成表のみで実現できるため Index Only Table と書かれたドキュメントもある。
通常表・ヒープ表
索引構成表と対比して、通常の表は「ヒープ表(Heap organized Table)」と呼ばれる形式であり、データの配置(並び順)についての 「しばり」 がないためデータは様々な場所に分散して配置される。ランダムというわけではなく Oracle がそのときに都合の良い場所に配置している。
索引構成表のメリット
索引構成表は主キーの値をキーにしてソートされた状態で格納される。主キー以外のデータもインデックスのリーフ内に格納されるため 「ヒープ表+主キー(インデックス)」という構成を 「索引構成表」の1つで構成することできる。
特にテーブルスキャンがインデックススキャンに相当するので主キーによる レンジスキャン(範囲検索)の場合に有効である。
また、ヒープ表と比較してデータがソートされた状態で保存されているため、キー圧縮機能を設定した場合のキーの圧縮率が優れている。
通常表と索引構成表の違いと制約(メリット/デメリット)
マニュアルを探せばわかることであるがネット上では Oracle8(8iではない) 時代のドキュメントを元にした情報が割と多いようなので Oracle 8〜10g の仕様の歴史を昔のドキュメントから引っ張り出して整理しておく。
バージョンはそれぞれのターミナルリリース(最終リリース)である。
通常表とIOT の違い | 通常表 | 索引構成表(IOT) |
Oralce 8.0.4 | Oracle 8i(8.1.7) | Oracle 9i R2 | Oracle 10g R2〜 |
一意性 | ROWID により一意 | 主キー により一意 | 同左 | 同左 | 同左 |
別のインデックス | 可能 | 作成できない | UROWID により作成可能 | 同左 | 同左 |
一意キーの作成 | 可能 | 作成できない | 作成できない | 作成可能 | 同左 |
アクセス方法 | ROWID を用いる | 主キーを用いる | 同左 | UROWID を用いる | 同左 |
フルアクセス | 全レコード戻す | 全レコードを主キー順に戻す | 同左 | 全レコード戻す(※1) | 同左 |
分散トランザクション レプリケーション | 可能 | 不可能 | 同左 | 記載なし | 同左 |
パーティション化 | 可能 | 不可能 | レンジパーティションのみ | レンジ、ハッシュ(※2) | レンジ、リスト、ハッシュ |
LOB 列(LONG は不可) | 可能 | 不可能 | 可能 | 同左 | 同左 |
別表とのクラスタ化 | 可能 | 不可能 | 同左 | 同左 | 同左 |
LogMiner | サポートされる | - | サポートされない | 同左 | サポート(※3) |
DBMS_REPAIR | サポートされる | - | サポートされない | 同左 | 同左 |
ダイレクトパスインサート | 使用できる | 使用できない | 同左 | 同左 | 同左 |
※ これらの索引構成表の制限については分散表記されたものを拾ってまとめた状態なので、かなり抜けがあると思われる。
また、マニュアルからの情報のみで実際に検証して確かめたものではない。
(※1) 主キー順で取得される保証が無くなったと思われる。
(※2) LOB を含む場合には レンジハッシュ化のみ
(※3) LOB および オーバーフローの無い索引構成表のみ
Oracle 11g R1 時点の索引構成表において仮想カラム(Virtual Column) はサポートされていない。
インデックス関連事項