SQL Serverの実行プランの基礎解説、SSMS(SQL Server Management Studio)での見方を初心者向けに解説します。
また、システム開発者、運用担当者向けに遅いSQLの原因調査方法を図解付きで説明します。
SQL Server の実行プランとは?
SQL Serverの実行プラン(実行計画)とは、データベースエンジン(オプティマイザ)が作成する処理手順書です。

SQL Serverの実行プランは、統計情報は密接に結びついています。
統計情報が正確でないと、オプティマイザは最適ではない実行プランを生成し、システム全体のパフォーマンス低下を引き起こします。
統計情報の説明は、「SQL Server統計情報の役割、実行方法の解説」を参照してください。
実行プランの役割
実行プランは、効率的にクエリを実行するためにプランを作成することです。
例えば、「社員」テーブルから「住居の都道府県」の社員を取得したい場合、「住居の都道府県」=’東京都’のデータは少ないと分かっていれば、インデックスを使って必要な行だけ探す(Index Seek)という高速な方法を選べます。
逆に、ほとんどのデータが ‘東京都’なら、全件読み込んだほうが速いです。

この実行計画は、SSMSを使ってどのようにデータを取ってくるか、コストをグラフィカルな画面で確認できます。

なぜSQLの性能改善に重要なのか
実行プランを使うと、クエリについて非効率な実行方法を見つけることができます。
性能が悪化しているSQLの、SQL文だけを見ても原因が分からない場合がありますが、実行プランを見ることで、テーブルに登録されているデータも考慮して、どこで負荷が発生しているのかを具体的に確認できます。
実行プランの種類
SQL Serverの実行プランには、大きく分けて「推定実行プラン」と「実際の実行プラン」の2種類があります。
どちらもSQLの実行方法を確認するためのものですが、取得できる情報や用途が異なります。
推定実行プラン(Estimated Execution Plan)
実際にクエリを実行せずに作成されるプランで、インデックスや統計情報をもとに予測されます。
クエリの設計段階で確認するのに便利です。
SSMSのクエリ作成画面(タブ)で、推定実行プランのアイコンをクリックすると実行プランが表示されます。

実際の実行プラン(Actual Execution Plan)
実際の実行プランは、SQLを実際に実行した状態で確認する実行プランです。
推定実行プランとの大きな違いは、実際に何件処理されたかを確認できる点です。
SSMSのクエリ作成画面(タブ)で、「実際の実行プランを含める」のアイコンをクリックしてONの状態にします。

その後「実行」をクリックすると処理件数などがリアルタイムに表示されます。

実行プランの見方
画面説明
上部にSQLのコストや不足しているインデックスがあれば、その情報が緑色で表示されます。
その下には処理した流れが、アイコン付きで横方向に表示されます。
矢印はデータ量を表しているので、太い線の場合その箇所がは重い原因となっている可能性があります。
各アイコンは次章で説明します。

各アイコンにはコスト割合が表示されていますが、実際の処理時間そのものではありません。
90% の演算子が速い場合もあります。
行数見積もり差異とは?
SQL Server は統計情報を利用して、「何件のデータが取得されるか」を予測しながら実行プランを作成します。
実行プランのアイコンには、Estimated Rows(予測行数)とActual Rows(実際の行数)が表示されます。
この2つの件数に大きな差がある場合、以下のような誤った実行プランをしてしまう可能性があり、遅くなる原因になります。
・Scan が増える
・Sort が発生する
・Key Lookup が大量発生する

行数見積もり差異の主な原因は以下です。
・統計情報が古い
・データ件数が大きく変化した
・WHERE条件の偏り
・パラメータスニッフィング
アイコンの説明
実行プランに表示されるアイコンの説明をデータ取得系、結合系、ソート・集計系の3つに分けて説明します。
データ取得系アイコン
データ取得はインデックスが無いテーブルは「Table」、インデックスが存在するテーブルは「Index」で始まります。
そして、全件読む場合は「Scan」、特定の行を読む場合は「Seek」という文字で表示されます。

Scan全権読み取りをしますが、必ずしも悪ではありません。以下の場合は Scan が最適な場合もあります。
・小さいテーブル
・数十〜数百件
・全件取得
結合系のアイコン
遅いSQLを実行プランから読み解く方法
結合演算子は、複数のテーブルのデータを組み合わせる処理を表します。
実行プランでは、テーブルの結合方法に応じて「Nested Loops」「Merge Join」「Hash Match」のいずれかのアイコンが表示されます。

ソート・集計系アイコン
ソート・集計演算子は、データの順序付けや集計処理を行う操作を表します。

まず確認すべきポイント
実行プランでコストが高い箇所を特定し、以下のポイントを確認します。
- Scanが発生していないか
- Key Lookupが多発していないか
- Sort処理が重くないか
- 推定行数と実際行数に差がないか
これらの確認ポイントについて、いくつか解消方法を紹介します。
Scanが発生する原因
Scanはテーブルやインデックス全体を読み込む処理です。
インデックスが存在しない場合は、インデックス作成で改善しますが、インデックスが利用できないSQLの書き方をしている場合は、SQLを修正することで改善できる場合があります。
例えば日付の条件指定をする場合、YEAR関数を使用するとScanになりやすくなります。
WHERE YEAR(CreateDate) = 2025この場合、以下のように条件を書き換えると、インデックスが利用されやすくなります。
WHERE CreateDate >= '2025-01-01'
AND CreateDate < '2026-01-01'Key Lookupが多発する原因
Key Lookupは、インデックスに含まれていない列の値を取得するために、追加でテーブルやクラスタ化インデックスへアクセスする処理です。
実行プラン上では「キー参照(Key Lookup)」としてアイコンで表示されますが、大量に発生するとパフォーマンスのボトルネックになります。
こうした場合、SSMS は「不足しているインデックス」の提案を表示し、付加列インデックスを作成することで Key Lookup の発生を減らすことができます。

Key Lookup自体は普通の動作です。
少量なら問題ありませんが、大量発生すると遅くなりやすいということです。
Sortが重くなるケース
大量データのソートは、非常に高コストになります。
この場合、ORDER BY列にインデックスを作成することで改善されることがあります。

まとめ
- SQL Serverの実行プランを確認すると、SQLの実行内容やボトルネックを把握できる
- SQL Serverの性能調査では、Estimated Execution PlanよりもActual Execution Planの確認が重要
- 実行プランでは、コスト割合だけでなく「Estimated Rows」と「Actual Rows」の差異も確認する
- 行数見積もり差異が大きい場合、SQL Serverが非効率な実行プランを選択する可能性がある
- Scan、Sort、Key Lookup が多発している箇所は、SQLが遅くなる原因になりやすい
- Index Seek は高速アクセスに利用されるが、Scan が最適なケースも存在する
- SQL Serverの実行プラン分析では、統計情報やインデックス設計も重要になる


コメント