全表走査・とは？初心者にも分かる意味と使い方共起語・同意語・対義語も併せて解説！

この記事を書いた人

高岡智則

年齢：33歳性別：男性職業：Webディレクター（兼ライティング・SNS運用担当）居住地：東京都杉並区・永福町の1LDKマンション出身地：神奈川県川崎市身長：176cm 体系：細身〜普通（最近ちょっとお腹が気になる）血液型：A型誕生日：1992年11月20日最終学歴：明治大学・情報コミュニケーション学部卒通勤：京王井の頭線で渋谷まで（通勤20分）家族構成：一人暮らし、実家には両親と2歳下の妹恋愛事情：独身。彼女は2年いない（本人は「忙しいだけ」と言い張る）

全表走査・とは？初心者にも分かる意味と使い方

全表走査とは、データベースの処理の中で、指定したテーブルの全行を順番に読み取ることを指します。条件に合う行がいくつあるかを、最初の行から順に確認していく動作です。

この方法は「インデックスを使わない場合でも、結果を得ることができる」ため、クエリの条件が複雑でインデックスが役に立たないときに現実的な選択肢になることがあります。ただし、テーブルの行数が増えると処理時間が急速に伸びるのが難点です。

いつ使われるのか

全表走査が有効なのは、テーブルが小さいときや、特定の列に対して有益なインデックスが存在しないときです。また、集計や結合の前処理で、全データを一度に読み取る必要がある場合にも使われます。

インデックス走査との違い

インデックス走査は、インデックスを使って必要な行だけを素早く見つけ、読み取るデータ量を抑えます。これにより、同じクエリでも全表走査より速くなることが多いです。クエリの条件とデータの分布次第で、どちらを選ぶかが大きく変わります。

パフォーマンスのポイント

大規模なテーブルで全表走査を避けたい場合は、以下の点を検討します。

・インデックスを追加する

・クエリを書き換えてインデックス走査が使われるようにする

・データを分割して処理するなど、作業の負荷を抑える工夫をする

実例と注意点

例として、SQLで「SELECT * FROM users;」というクエリを実行すると、多くのデータベースはこのクエリに対して全表走査を行う可能性がありますが、条件を付けるとインデックス走査へ変わることがあります。ここで重要なのは、適切なインデックスの有無が、実行時間を大きく左右する点です。

比較表

走査の種類	特徴	メリット	デメリット
全表走査	テーブルの全行を順次読み取る	インデックスがなくても動作する	大規模データでは遅くなることが多い
インデックス走査	インデックスを使い、必要な行だけを読み取る	通常は速い / I/Oを減らせる	適切なインデックスが必要

まとめ

総括として、全表走査はシンプルで確実な読み取り方法ですが、データ量が大きくなるほど非効率になる可能性が高くなります。実務では、インデックス走査を優先して使えるよう、インデックス設計とクエリの工夫を行いましょう。

全表走査の同意語

フルテーブルスキャン: データベースがテーブル全体を走査して、指定した条件に一致する行を見つける処理です。インデックスを使わず全件を順番に比較するため、テーブルの規模が大きいと遅くなることがあります。
全件走査: テーブルの全行を一括で調べる処理のこと。通常はインデックスを使わず全件を確認するため、検索条件によっては時間がかかる場合があります。
フルスキャン: 全件走査とほぼ同義の口語表現です。テーブルの全行を走査して条件に合うデータを探します。
全行走査: テーブルの“行”全体を順次走査すること。インデックスを使わず全件を確認するケースで使われる表現です。
テーブル全走査: テーブル全体を走査してデータを調べる処理。条件に合うレコードを得るために全件を検査することを指します。
全件検索: テーブル内の全レコードを対象に検索すること。通常はインデックスを使わず全件を比較する場合に用いられる表現です。

全表走査の対義語・反対語

インデックス走査: データを全表走査するのではなく、インデックスを用いて必要なデータだけを絞り込み、取得する走査方法。検索条件に合致する行を効率的に取り出すのが特徴。
インデックス検索: インデックス構造を使って、条件に合うデータを素早く探し出す方法。全表走査の対義語としてよく使われる表現。
インデックスアクセス: インデックスを経由してデータへアクセスすることを指す。データの読み取りを高速化する目的で用いられる。
インデックス利用: データ取得時にインデックスを活用すること。全表走査を避け、効率的な検索を実現する手法。
インデックススキャン: インデックスを利用してデータを走査・取得する方法。全表走査に対する代表的な対義語。

全表走査の共起語

インデックス: データ列に対して検索を高速化するデータ構造。適切な列に作成すると、全表走査を回避しやすくなる。
インデックススキャン: インデックスを使ってデータを読み出す方法。条件に合う行を素早く探せる場合に用いられる。
テーブルスキャン: テーブル全体を順番に読み込んで条件を満たす行を探す方法。インデックスが使えないときの基本的な読み方。
実行計画: データベースがクエリをどう実行するかの設計図。全表走査が選択されることもある。
クエリ最適化: データベースがより効率的な実行計画を選ぶプロセス。インデックスや統計情報を考慮して決定する。
統計情報: データ分布や行数など、最適な実行計画を決めるための情報。最新の方が有効。
統計情報不足: 統計情報が不足すると、最適化が不確かな推定になり、全表走査が選択されやすくなる。
選択性: 条件がデータをどれだけ絞り込むかの指標。低いと全表走査になりやすい。
WHERE句: 検索条件を指定するSQLの一部。適切に書くとインデックスが活きやすくなる。
ディスクI/O: データをディスクから読み出す入出力作業。全表走査では多くのI/Oが発生することがある。
CPUコスト: データ処理の計算負荷。全表走査はCPUにも負担がかかることがある。
バッファプール: RAM上のデータを一時的に保持する領域。キャッシュが温まっていると全表走査の実行が速くなることがある。
キャッシュ: よく使うデータを高速に再利用する仕組み。データがキャッシュにあれば全表走査も速くなることがある。
パーティショニング: 大きなテーブルを分割して管理する方法。適切な分割で全表走査の対象を限定できる。
データ量: テーブルの総データ量。量が多いほど全表走査のコストは高くなる傾向。
データ分布: 値の出現パターン。偏っているとインデックスの効果が変わることがある。
DBMS: データベース管理システム。実行計画の生成や最適化を担うソフトウェア。
MySQL: 人気のあるDBMSの一つ。実行計画の表示やインデックスの挙動を学ぶ入門先として適切。
PostgreSQL: 別の主要DBMS。実行計画の解釈や全表走査の理解に役立つ。
SQL Server: MicrosoftのDBMS。クエリプランの表示機能などが充実。
Oracle: Oracle Database。統計情報の管理や実行計画の解釈で学べる。
クエリヒント: 実行計画を優先させる指示。インデックス使用を強制したいときなどに使う。
実行計画の表示: EXPLAINや実行計画のビューで、全表走査が選択されているかを確認する作業。

全表走査の関連用語

全表走査: テーブルの全行を順番に読み込む処理。インデックスが使えない/使われない場合に発生し、テーブルが大きいとI/Oが多く遅くなる。
テーブルスキャン: 全表走査の別称。DBMSがテーブル全体を読み込む基本的な読み取り手法。
シーケンシャルスキャン: 行を順番に読み進める走査。実質的には全表走査と同義になることが多い。
インデックス走査: インデックスを使って絞り込み、該当する行だけを読み出す方式。
インデックス未使用: クエリが最適にインデックスを使えず、テーブル全体を読まざるを得ない状態。
実行計画: データベースがクエリをどう処理するかの設計図。
EXPLAIN / EXPLAIN ANALYZE: 実行計画を表示するコマンド。ANALYZEを付けると実際の実行時間や行数も分かる。
統計情報: データ分布の統計データ。クエリ最適化に使われ、選択性の見積もりを左右する。
カーディナリティ / 選択性: 条件に合う行の数の予測指標。高い選択性は少数の行を絞り込むことを意味する。
インデックスの選択性: インデックスが条件に対して有効に絞り込める度合い。高いほどインデックスの利用が有利。
B-treeインデックス: 最も一般的なインデックス。範囲検索に強い。
Hashインデックス: 等価条件に強いインデックス。範囲検索には不向き。
GiSTインデックス: 汎用的なインデックス。特殊なデータ型で使われる。
GINインデックス: 複数値の検索に向くインデックス。全文検索などに使われる。
BRINインデックス: 大きなテーブルで連続性を活かす軽量インデックス。
カバーリングインデックス / インデックスオンリースキャン: インデックスだけで全ての必要列を取得できる場合、テーブルアクセスを省略できる。
パーティショニング: 大きなテーブルを分割して管理する技術。
パーティションプルーニング: 不要なパーティションを実行計画から除外して走査コストを減らす。
Bitmap Index Scan: 複数条件でインデックスを連携してビットマップを作成し、後で実データを読み込む手法（主に複数条件時）。
Bitmap Heap Scan: 生成したビットマップに基づいて実データを読み込む処理。
クラスタ化 / 非クラスタ化インデックス: データをインデックス順に物理的に並べているかどうか。クラスタ化はデータの並びをインデックス順に近づける。
実行計画のコスト: コスト値が低い方をオプティマイザーが選ぶ。コストは I/O・CPUの見積もりを元に算出される。
ワークメモリ (work_mem): ソートやハッシュ作成などに使われるメモリ容量。大きいとディスクI/Oを減らせる場合がある。
並列クエリ / パラレル実行: 複数のCPUで同時に処理して全体を速くする。全表走査でも効果的な場合がある。
フィルタ条件: WHERE句の条件。インデックス利用可否の決定要因になる。
ジョイン戦略: 結合時に使われる計画。Nested Loop Join / Hash Join / Merge Join など、スキャンの読み出し方に影響する。
ソート / ORDER BY: 結果を並べ替える処理。追加の読み込みやメモリを必要とすることがある。
グループ化 / GROUP BY: 集約処理。大規模データではソート・ハッシュ等が発生し、走査計画に影響。
ヒストグラム / 統計データ: データ値の分布を示す統計。最適化の推定精度を左右する。
ANALYZE / VACUUM: 統計情報を更新（ANALYZE）や不要なデータを掃除（VACUUM）する保守作業。
クエリヒント / パラメータチューニング: インデックスの利用を促すヒントや、DB設定（例: work_mem）を調整する方法。