
SQL実行時は、一旦、オプティマイザが実行計画を作成します。
その後、テーブルへアクセスして、データ処理を行いますが、その際のアルゴリズムも色々ありますのでご紹介させて頂きます。
ちなみに、これを専門用語で「アクセスパス」と呼びます。
- フルテーブルスキャン(表探索)
- ROWIDアクセス
- 索引スキャン(索引探索、インデックススキャン)
- 全索引スキャン
フルテーブルスキャン(表探索)
目的のデータが見つかったとしても、全てのデータにアクセスします。
そのため、データ件数が多いほど、実行時間がかかってしまいます。テーブルの大部分のデータを取得する処理以外では避けるべきです。
なお、低いHWM(ハイウォーターマーク)の下のブロックは隣接しているため、一度に複数のブロックを読み取ることでスキャンを高速化できる。(チューニングにはDB_FILE_MULTIBLOCK_READ_COUNTなどの初期化パラメータを用いる。)
ROWIDアクセス
テーブルのデータにアクセスする手法として、最も高速になります。
ROWIDを用いて、目的のデータが格納されている行に直接アクセスを行います。
ただ、テーブルの移動や、DBのエクスポート、インポートをするとROWIDが変わってしまいますので、常にこれを利用するということはできません。
アプリで取得した行に、再度アクセスする場合の用途のみに限定して使います。
索引スキャン(索引探索、インデクススキャン)
索引を使用して、ROWIDを取得後、データを検索します。データ量が少ない場合は「フルテーブルスキャン」よりも高いパフォーマンスを出してくれますが、レコードの15%を超える量の検索の場合は、フルテーブルスキャンよりも検索速度が低下します。
なお、インデクススキャンは「完全一致検索」だけでなく「前方一致検索」でも利用されています。
インデックススキャンにするには対象カラムについてインデックスを設定する必要があります。インデックスの作成方法については下記の記事で解説しています。
全索引スキャン
索引の値を取得するだけで、ROWIDを取得せずに、データを取得できるので、索引スキャンよりも高速。
ただし、全索引スキャンを行うためには、下記の前提条件になっていた場合のみ実行されます。
- SELECT文と、WHERE句に記述する全ての列が、索引になっている。
- 索引内部の行の10%が問い合わせから戻されること。
この記事へのコメントはありません。