SQL Serverの実行計画に表示されるTable Scan・Index Seek・Index Scanの違いをわかりやすく解説

SQL Server

SQL Serverでクエリの速度改善を行う際、実行計画を確認すると「Table Scan」「Index Seek」「Index Scan」といった処理が表示されることがあります。これらはSQL Serverがデータを取得するときに、テーブルやインデックスをどのように検索しているかを示す重要な情報です。

それぞれの違いを理解すると、なぜSQLが遅いのか、インデックス設計やクエリ改善が必要なのかを判断しやすくなります。この記事では、SQL Serverの代表的な検索方法であるTable Scan・Index Seek・Index Scanの意味や使い分けについて詳しく解説します。

SQL Serverの実行計画とは何か

SQL Serverの実行計画とは、入力されたSQL文をどのような手順で処理するかをSQL Serverが決定した結果を表したものです。

例えば、100万件のデータが入ったテーブルから1件の情報を探す場合でも、SQL Serverは「全件確認する」「インデックスを利用して目的のデータだけ探す」など複数の方法を選択できます。

実行計画には、SQL Serverが選択した検索方法や処理コストが表示されるため、パフォーマンスチューニングでは非常に重要な確認ポイントになります。

Table Scanとはテーブル全体を検索する処理

Table Scanとは、テーブル内のすべてのデータを順番に読み取って条件に一致する行を探す処理です。

例えば、社員テーブルに100万件のデータがあり、その中から社員番号を検索するとします。このとき社員番号のインデックスが存在しない場合、SQL Serverは先頭から最後まで確認する必要があります。

このような処理がTable Scanです。データ量が少ないテーブルでは問題にならない場合もありますが、大量データを扱う場合は処理時間が長くなる原因になります。

特徴 内容
検索範囲 テーブル全体
速度 大量データでは遅くなりやすい
発生しやすい状況 適切なインデックスがない場合

Index Seekとは必要なデータだけを探す処理

Index Seekとは、インデックスを利用して目的のデータが存在する場所を効率的に検索する処理です。

例えば、社員番号に対してインデックスが作成されている場合、SQL Serverはインデックスを利用して該当する社員の位置を直接探します。

本棚で例えると、Table Scanが本棚にある本を最初から順番に確認する方法なのに対して、Index Seekは図書館の検索システムで目的の本の場所をすぐ探すようなイメージです。

大量データから少数の行を取得する検索では、一般的にIndex Seekが効率の良い処理になります。

Index Scanとはインデックス全体を確認する処理

Index Scanとは、インデックスを利用するものの、インデックス内の広い範囲または全体を読み取る処理です。

Table Scanではテーブルそのものを確認しますが、Index Scanではインデックスの内容を順番に確認します。インデックスはテーブルよりデータ量が少なく整理されているため、場合によってはTable Scanより効率的になることがあります。

例えば、一覧表示のように多くのデータを取得する処理では、Index ScanがSQL Serverによって最適な方法として選択される場合があります。

Index SeekとIndex Scanの違い

Index SeekとIndex Scanは名前が似ていますが、検索範囲が大きく異なります。

処理 検索方法 向いている処理
Index Seek 必要な部分だけ検索 特定の1件や少数データ取得
Index Scan インデックスを広く検索 大量データ取得や集計

例えば、「東京都に住んでいる社員を1人検索する」という処理ではIndex Seekが適しています。一方で、「全社員の住所一覧を取得する」という処理ではIndex Scanが適している場合があります。

そのため、Index Scanが必ず悪い処理というわけではありません。重要なのは、SQL Serverがその処理を選択した理由が、実際の処理内容に合っているかどうかです。

Table ScanやIndex Scanが発生する原因

実行計画でTable ScanやIndex Scanが多く発生している場合、必ずしも問題とは限りません。しかし、検索条件に対して効率的なインデックスが存在しない可能性があります。

代表的な原因には以下があります。

  • 検索条件に利用する列へインデックスがない
  • WHERE句でインデックスを利用しにくい書き方をしている
  • 取得するデータ件数が多すぎる
  • 統計情報が古く適切な実行計画を作成できていない

例えば、名前検索を頻繁に行う社員テーブルで名前列にインデックスがなければ、SQL Serverは全件確認する必要があり、Table Scanになる可能性があります。

実行計画を見るときに注目すべきポイント

SQL Serverのパフォーマンス改善では、単純にTable ScanやIndex Scanをなくすことだけを目的にすると逆効果になる場合があります。

確認するときは、以下のポイントを見ることが重要です。

  • 処理コストが高い部分はどこか
  • 実際に読み込んでいる行数は多すぎないか
  • 推定行数と実際の行数に大きな差がないか
  • 不要なインデックスや不足しているインデックスがないか

例えば、100万件のテーブルから90万件取得する処理では、Index SeekよりもScan処理の方が効率的な場合があります。処理内容に合わせて判断することが大切です。

まとめ

SQL Serverの実行計画に表示されるTable Scan、Index Seek、Index Scanは、データ検索方法の違いを表しています。

Table Scanはテーブル全体を確認する処理、Index Seekはインデックスを利用して必要なデータだけを探す処理、Index Scanはインデックスを広く確認する処理です。

一般的には少量データの検索ではIndex Seekが効率的ですが、Scan処理が必ず悪いわけではありません。SQLの目的や取得データ量を考慮しながら実行計画を確認することで、適切なデータベースチューニングができるようになります。

コメント

タイトルとURLをコピーしました