※お役に立てたらストック、いいねをよろしくお願いします！！
＜本記事のターゲット層＞
- SQL Serverを業務で利用しており、SQLのパフォーマンス改善に取り組みたいエンジニア
- 実行プランは見たことがあるが、実行時間やIOとの関係をどう活用すればいいか悩んでいる方
- チューニングの詳細な手法に入る前に「まず比較検証できる環境を整えたい」と考えている方
- チームや上司に「なぜこのSQLが速い（遅い）のか」を説明できるようになりたい方
🟦 1. はじめに
SQLを書いていると「期待したよりも遅い」「なぜか特定のクエリだけ重い」と感じる場面があります。
原因はインデックス設計や結合方法など多岐にわたりますが、まず大事なのは “どのSQLがどのくらい遅いのか”を自分の目で確認すること です。
本記事では、SQL Server Management Studio（SSMS）を使って実行時間やIOを計測し、複数のSQLを比較するための基本的な手順を紹介します。
いきなり高度なチューニングに入るのではなく、実務で「遅いSQLに出会ったときに最初にやるべきこと」に焦点を当てています。
🟩 2. SQL実行前にやること
まずは、SQL Management StudioでSQLを実行する前に、SQL文の手前で以下のステートメントを記述します。
SET STATISTICS IO ON; SET STATISTICS TIME ON; SET STATISTICS PROFILE ON;
OFFにしないとステートメントが有効化され続けるため、SQL文の終わりに必ず以下のステートメントを記述してください。
SET STATISTICS IO OFF; SET STATISTICS TIME OFF; SET STATISTICS PROFILE OFF;
🟨 3. 比較するSQL文を記述する
前述したONとOFFのステートメントの間に、比較するSQL文を2つ記述します。
例）
SET STATISTICS IO ON; SET STATISTICS TIME ON; SET STATISTICS PROFILE ON;
SELECT * FROM employee where id = '0001'
SELECT id FROM employee where id = '0001'
SET STATISTICS IO OFF; SET STATISTICS TIME OFF; SET STATISTICS PROFILE OFF;
🟧 4. SQL実行後に結果を確認する
メッセージタブにSQL実行結果が表示されます。
「～行に影響しました」の手前にあるのが実行にかかった時間、後にあるのはIOの影響になります。
以下はあくまでサンプルになるため、提示したemployeeの実行結果とは行数等に違和感があると思いますが、表示される項目は実際のものと同じです。
SQL Server 実行時間:
、CPU 時間 = 0 ミリ秒、経過時間 = 0 ミリ秒。
(69 行に影響しました)
テーブル 'employee'。スキャン数 1、論理読み取り数 2、物理読み取り数 0、ページ サーバー読み取り数 0、先読みの読み取り数 0、ページ サーバー先読みの読み取り数 0、LOB 論理読み取り数 0、LOB 物理読み取り数 0、LOB ページ サーバー読み取り数 0、LOB 先読みの読み取り数 0、LOB ページ サーバー先読みの読み取り数 0。
(13 行に影響しました)
(1 行処理されました)
SQL Server 実行時間:
、CPU 時間 = 0 ミリ秒、経過時間 = 4 ミリ秒。
(69 行に影響しました)
テーブル 'employee'。スキャン数 0、論理読み取り数 158、物理読み取り数 0、ページ サーバー読み取り数 0、先読みの読み取り数 0、ページ サーバー先読みの読み取り数 0、LOB 論理読み取り数 0、LOB 物理読み取り数 0、LOB ページ サーバー読み取り数 0、LOB 先読みの読み取り数 0、LOB ページ サーバー先読みの読み取り数 0。
(13 行に影響しました)
(1 行処理されました)
SQL Server 実行時間:
、CPU 時間 = 0 ミリ秒、経過時間 = 2 ミリ秒。
SQL Server 実行時間:
、CPU 時間 = 0 ミリ秒、経過時間 = 0 ミリ秒。
完了時刻: 2025-08-28T12:02:46.7402678+09:00
結果タブには実際に実行された処理の詳細が表示されます。
各項目の説明についてはこちらのページで詳しく書かれていますので参考になります。
また、[クエリ] -> [実際の実行プランを含める]をクリックすることで、SQL実行時に実行プランを図で視覚的に確認することもできます。
表示はこちらがお勧めです。XMLでダウンロードすることもできるので、AIに質問するときにも活用できます。
🟧 5. まとめ
SQLについてはネット情報に頼ると何が正解か分からなくなるときがありますよね。
そうしたときに「自分の眼で見て確認をする」ということがとても大事です。
パフォーマンスが悪いSQLを組んだときに「ネットに載っていたんです」「AIに聞いたらそう答えたんです」ではビジネスなので無責任行為になります。
しっかりと確認をして「このSQLで比較した結果、こちらの方が早かったのでそうしました」と説明できるほうが技術力の信頼につながります。
※お役に立てたらストック、いいねをよろしくお願いします！！