IndexScan では、探索条件を満たすローを判断するときにインデックスを使用します。インデックス・スキャンは、条件に合うローのセットを削減してからテーブルにアクセスするために役立ちます。インデックス・スキャンによって、ローをソートして返すことができます。

IndexScan は、短いプランに correlation-name<index-name> と表示されます。ここで、correlation_name は FROM 句に指定された相関名、または指定されていない場合はテーブル名です。index_name はインデックス名です。

インデックスは、大規模なテーブルから少数のローを効率的に読み込むメカニズムを提供します。ただし、テーブルから多数のローを読み込む場合は、インデックス・スキャンは逐次スキャンよりもコストが高くなる場合があります。インデックス・スキャンでは、ページがデータベースからランダムに読み込まれるため、逐次読み込みよりコストが高くなります。また、あるテーブル・ページに探索条件を満たす複数のローがあると、インデックス・スキャンはそのページを複数回参照します。インデックス・スキャンによって一致するページが少数しかないと、そのページがキャッシュに残り、複数のアクセスによる余分な I/O は生じません。ただし、多数のページが探索条件と一致すると、すべてがキャッシュに収まらないことがあります。このため、インデックス・スキャンではディスクから同じページが複数回読み込まれることになります。

探索条件が検索引数可能であり、オプティマイザによる探索条件の選択性推定が低いためにインデックス・スキャンの方が逐次テーブル・スキャンより低コストの場合、オプティマイザはインデックス・スキャンを使用して探索条件を満たします。

インデックス・スキャンは、ローがインデックスからフェッチされた後で検索引数不可能な探索条件を評価することもできます。インデックス・スキャンで条件を評価することは、インデックス・スキャン後にフィルタ内の条件を評価するより多少効率的です。

一致する探索条件がない場合でも、インデックスは、順序付けの要件を満たすためにも使用できます。これは、ORDER BY 句で明示的に定義することも、GROUP BY または DISTINCT 句で暗黙的に必要とすることもあります。順序付き GROUP BY 方式と順序付き DISTINCT 方式は、ハッシュベースのグループ化や DISTINCT より短い時間で最初のローを返すことができます。ただし、結果セット全体を返すときには低速になる場合があります。

optimization_goal が first-row に設定されていると、オプティマイザは逐次テーブル・スキャンよりインデックス・スキャンを優先する傾向があります。これは、テーブル・スキャンに比べると、インデックスの方がクエリの最初のローを短時間で返す傾向があるためです。

クエリを記述するときに、インデックス・ヒントを指定して、オプティマイザが使用するインデックスとその使用方法を指定することもできます。ただし、インデックス・ヒントはクエリ・オプティマイザの意思決定論理を上書きするため、経験のあるユーザのみ使用してください。インデックス・ヒントを使用すると、次善のアクセス・プランが使用され、パフォーマンスが低下することがあります。FROM 句を参照してください。