Oracleの索引構成表はいつ使用すべきですか？または、私はいつすべきではないのですか？
インデックス構成テーブル（IOT）は、インデックス構造に格納されたテーブルです。ヒープに格納されているテーブルは整理されていないのに対し、IOTのデータは格納され、主キーでソートされます（データはインデックスです）。 IOTは「通常の」テーブルのように動作し、同じSQLを使用してそれらにアクセスします。
適切なリレーショナルデータベース内のすべてのテーブルに主キーがあるはずです...データベース内のすべてのテーブルに主キーがある場合、常にインデックス編成されたテーブルを使用する必要がありますか？
私は答えがノーだと思います、それでいつインデックス編成されたテーブルはnotが最良の選択ですか？
基本的に、索引構成表は、表のない索引です。したがって、列が主キーと最大1つの他の列で構成されるテーブルがある場合、INDEX ORGANIZEDの候補となる可能性があります。
ただし、非主キー列に追加のインデックスが必要であると考えている場合は、通常のヒープテーブルを使用することをお勧めします。したがって、ほとんどのテーブルはおそらく追加のインデックスを必要とするため、ほとんどのテーブルはIOTには適していません。
実際には、索引構成表は参照データ、コード検索業務である可能性が最も高いです。ほとんどの場合、アプリケーションテーブルはヒープで構成されています。
私はそれらを非常に狭いテーブル（多対多のテーブルを解決するために使用される結合テーブルなど）について検討します。とにかく、テーブルのすべての列がインデックスに含まれる場合は、IOTを使用するべきではありません。
Richard Footeによって議論されているように、小さなテーブルはIOTの良い候補になる可能性があります here
次の種類のテーブルは、IOTの優れた候補と考えています。
- 「小さい」「ルックアップ」タイプのテーブル（たとえば、頻繁に照会され、まれに更新され、比較的少数のブロックに収まる）
- とにかく、すべての列をカバーするインデックスを持つテーブル（つまり、インデックスがデータの100％を複製する場合、テーブルが使用するスペースを節約することもできます）
Oracle Concepts ガイドから：
索引構成表は、関連するデータを一緒に格納する必要がある場合、またはデータを特定の順序で物理的に格納する必要がある場合に役立ちます。このタイプのテーブルは、情報の取得、空間（「Oracle Spatialの概要」を参照）、およびOLAPアプリケーション（「OLAP」を参照）によく使用されます。
これは、AskTomからの question も興味深いかもしれません。特に、誰かがシナリオを提供し、IOTがヒープ構成のテーブルよりも優れているかどうかを尋ねる場合、トムの応答は次のとおりです。
私たちは一日中仮説を立てることができますが、それを測定するまで、確かなことは決してわかりません。
キー、キー全体、およびキーのみでそのテーブルのデータにアクセスする場合は、通常、インデックス構成テーブルが適しています。
さらに、他のデータベース機能が索引構成表で使用できることと使用できないことには多くの制限があります-少なくとも1つのバージョンでは、索引構成表でロジカルスタンバイデータベースを使用できなかったことを思い出します。索引構成表は、他の機能を使用できない場合は適切な選択ではありません。
IOTが実際に保存するのは、テーブルセグメントの論理読み取りのみです。IOT/インデックスに2つまたは3つ以上費やした可能性があるため、小さなデータセットを除いて、これは必ずしも大きな節約とは限りません。
特に大きなテーブルでルックアップを高速化するために考慮すべきもう1つの機能は、単一のテーブルハッシュクラスタです。正しく作成された場合、IOTよりもデータが大きいため、IOTよりも効率的です。IOTは、リーフノードを見つけるために複数の論理I/Oを必要とするインデックスです。