完全なテーブルスキャン

フルテーブルスキャン（シーケンシャルスキャンとも呼ばれる）は、データベース上で実行されるスキャンであり、テーブルの各行がシーケンシャル（シリアル）順序で読み取られ、検出された列が条件の妥当性についてチェックされます。^[1]フルテーブルスキャン^[2]は、複数のシークとコストのかかるディスクからメモリへの転送で構成されるディスクからの大量のI/O読み取りが必要なため、通常、テーブルをスキャンする方法の中で最も低速です。

データベースでは、インデックスが作成されていないクエリは完全なテーブル スキャンとなり、データベースはテーブルの各レコードを処理して、指定された要件を満たすすべてのレコードを検索します。クエリがテーブルから数行だけを選択する場合でも、テーブル全体のすべての行が検査されます。これにより通常はパフォーマンスが最適ではなくなりますが、テーブルが非常に小さい場合や、インデックスを最新の状態に保つためのオーバーヘッドが大きい場合は許容される可能性があります。

選択する上で最も重要な要素は速度です。つまり、フルテーブルスキャンは、最も高速で、別のアクセスパスを使用できない場合に使用する必要があります。フルテーブルスキャンの例をいくつか示します。^[3]

• インデックスなしインデックスが存在しないため、オプティマイザーは完全なテーブルスキャンを使用する必要があります。
• 行数が少ないテーブルが小さいため、フル テーブル スキャンのコストはインデックス範囲スキャンよりも低くなります。
• クエリが SELECT COUNT(*) を処理したとき、列に null が存在しました。クエリは、一般的なインデックス内の null 列の数をカウントします。ただし、SELECT COUNT(*) では null 列の数をカウントできません。
• クエリは選択的ではありません。返される行の数が多すぎて、テーブル全体のほぼ 100% を占めます。これらの行は選択的ではありません。
• テーブル統計は更新されません。テーブル内の行数は以前より多くなっていますが、テーブル統計はまだ更新されていません。オプティマイザーは、インデックスを使用する方が高速であると正しく推定できません。
• テーブルには高度な並列処理があります。高度な並列処理テーブルでは、オプティマイザが完全なテーブルスキャンを使用するため、オプティマイザが正しい方法から逸脱します。
• フル テーブル スキャンのヒントこのヒントにより、オプティマイザーはフル テーブル スキャンを使用できるようになります。

最初の例は、果物テーブル内の色が赤であるすべての果物の名前を返すSQLステートメントを示しています。果物テーブルに色列のインデックスがない場合、データベース エンジンは果物内のすべての行を読み込んで検査し、各行の色を「赤」と比較する必要があります。

SELECT name FROM fruit WHERE color = 'red' ;   
     
      

2 番目の例は、fruits テーブル内のすべての果物の名前を返す SQL ステートメントを示しています。このステートメントには条件 (WHERE 句) がないため、fruits テーブルの名前列にインデックスがあっても、データベース エンジンはテーブル スキャンを使用してこのクエリのデータをロードして返します。これは、テーブルに直接アクセス (つまりスキャン) する方が、インデックスの追加の抽象化レイヤーを介してテーブルにアクセスするよりも高速であるためです。

果物から名前を選択   
     

3 番目の例は、SQL エンジンがテーブル スキャンではなくインデックスを使用することがほぼ確実となる反例です。この例では、前の例とほぼ同じクエリを使用しますが、返される名前がアルファベット順になるように ORDER BY 句を追加します。fruits テーブルの名前列にインデックスがあると仮定すると、データベース エンジンはそのインデックスを使用して名前を順番に返します。これは、インデックスの追加の抽象化レイヤーを介してテーブルにアクセスすると、要求された順序で行が返されるという利点があるためです。エンジンがテーブル スキャンを使用して行をロードした場合、返された行を並べ替えるという追加の作業を実行する必要があります。極端な場合 (たとえば、データベース エンジンによって維持される統計で、テーブルに含まれる行数が非常に少ないことが示されている場合) には、オプティマイザーがこの種のクエリに対してテーブル スキャンを使用することを決定する場合があります。

果物から名前を選択名前で注文   
     
  

長所:

• データベース システムは毎回テーブル全体を行ごとにスキャンする必要があるため、コストは予測可能です。
• テーブルがデータベース ブロック バッファの 2% 未満の場合、テーブルの完全スキャンはより高速になります。

短所:

• フル テーブル スキャンは、インデックスがないか、SQLによってインデックスが使用されていない場合に発生します。フル スキャン テーブルの結果は通常、インデックス テーブル スキャンよりも遅くなります。状況は、テーブルが大きいほど、データが返される速度が遅くなるということです。
• 不必要なフルテーブルスキャンは、データベース全体にプロセスの負担をかけ、大量の不要なI/Oにつながります。

• データベース
• データベースインデックス
• 最適化コンパイラ
• クエリプラン
• クエリの最適化
• 構文

• Oracle フルテーブルスキャンのヒント