SQLの実行計画とは、データベースがSQLをどのような順番で処理するかを示した計画のことです。 かんたんに言うと、SQLを実行するときの「処理の道順」です。
SQLが遅いときは、どこで時間がかかっているのかを調べる必要があります。 その手がかりになるのが、実行計画です。
この記事では、SQLの実行計画とは何か、見方、取得方法、コストの意味、SQLが遅いときに見るポイントを初心者向けにわかりやすく解説します。
関連するIT用語をまとめて確認したい方は、IT用語一覧もあわせてご覧ください。
SQLの実行計画とは
SQLの実行計画とは、データベースがSQLを処理するときの手順を示したものです。 SQLとは、データベースに対して「データを探して」「追加して」「変更して」などと指示するための言葉です。
データベースとは、たくさんの情報を整理して保存する仕組みです。 たとえば、会員情報、商品情報、注文履歴などを保存するときに使われます。
同じ結果を出すSQLでも、処理の方法はいくつかあります。 その中から、データベースが「この順番で処理しよう」と決めた内容が実行計画です。
データベースがSQLを処理する道順のこと
実行計画は、データベースの中で作られる処理の道順です。 どの表から読むか、どの条件で絞るか、どの順番でデータをつなげるかが示されます。
ここでいう表とは、データを行と列で整理したものです。 Excelの表をイメージすると分かりやすいです。
行とは、表の中の1件分のデータです。 列とは、名前、住所、金額などの項目です。
実行計画を見ると、データベースがどのようにSQLを処理しようとしているのかが分かります。 そのため、SQLが遅い原因を調べるときに使われます。
SQLが遅い原因を調べるために使う
SQLが遅くなる理由はいくつもあります。 たとえば、大量のデータを読んでいたり、必要のない並べ替えをしていたりします。
実行計画を見ると、どこで時間がかかりやすい処理が起きているのかを探しやすくなります。 ただし、実行計画だけで全部が分かるわけではありません。
実行計画は、あくまで原因を探すための手がかりです。 実際のデータ量や実行時間もあわせて見ることが大切です。
実行計画を読む前に知っておきたい基本用語
実行計画には、SQLやデータベースの用語が多く出てきます。 先に基本の言葉を知っておくと、本文を読みやすくなります。
| 用語 | かんたんな意味 |
|---|---|
| SQL | データベースに指示を出すための言葉 |
| データベース | たくさんの情報を整理して保存する仕組み |
| テーブル | データを行と列で整理した表 |
| 行 | 表の中の1件分のデータ |
| 列 | 名前、住所、金額などの項目 |
| インデックス | データを探しやすくするための目印 |
| 結合 | 複数の表をつなげて、ひとつの結果として見ること |
| コスト | 処理の重さを表す目安 |
| rows | 処理する行数の見込み |
| 統計情報 | データベースがデータ量を判断するための情報 |
実行計画には英語の表示が多く出ますが、最初からすべてを覚える必要はありません。 まずは「どこで多くのデータを読んでいるか」を見るだけでも十分です。
実行計画を身近な例でいうと
実行計画は、目的地までの道順を決めるカーナビに近いものです。 目的地が同じでも、通る道によって到着までの時間は変わります。
データベースでも同じです。 同じ結果を返すSQLでも、どの表から読むか、どの順番で処理するかによって速さが変わります。
目的地までの道順を決めるカーナビのようなもの
カーナビは、目的地までの道を考えます。 高速道路を使うのか、近道を使うのか、混んでいる道を避けるのかを判断します。
実行計画も同じように、データベースが処理の道順を考えます。 どの表を先に読むか、どの条件で絞るかを決めます。
ただし、カーナビの例はあくまでイメージです。 ITの意味では、実行計画は、データベースがSQLを処理する前に作る「処理の進め方」を指します。
同じ目的地でも通る道によって時間が変わる
目的地が同じでも、遠回りをすれば時間がかかります。 混んでいる道を通っても時間がかかります。
SQLも同じです。 必要なデータは同じでも、処理の順番がよくないと時間がかかります。
実行計画を見ることで、遠回りのような処理になっていないかを確認できます。 これが、SQLの速度改善で実行計画が使われる理由です。
実行計画で分かること
実行計画を見ると、SQLの処理の流れが分かります。 特に、データの読み方、処理する行数、結合の順番、並べ替えの有無が大切です。
最初から全部を理解する必要はありません。 まずは「どの表を、どれくらい読んでいるか」を見るだけでも役に立ちます。
どのテーブルからデータを読むか
テーブルとは、データを入れておく表のことです。 会員テーブル、注文テーブル、商品テーブルのように分けて保存されます。
実行計画では、どのテーブルから先に読むかが分かります。 先に読むテーブルが変わると、処理にかかる時間も変わることがあります。
インデックスを使っているか
インデックスとは、データを探しやすくするための目印です。 本の索引のようなものです。
本で言葉を探すとき、最初のページから全部読むと時間がかかります。 索引があれば、目的のページを見つけやすくなります。
データベースでも、インデックスが使われると目的のデータを探しやすくなることがあります。 実行計画を見ると、インデックスを使っているかを確認できます。
どの順番でデータを結びつけるか
SQLでは、複数の表をつなげて、ひとつの結果として見ることがあります。 たとえば「注文の表」と「会員の表」をつなげると、誰が何を買ったかを見られます。
このように、複数の表をつなげることを結合といいます。 結合の順番によって、処理にかかる時間が変わることがあります。
実行計画では、結合の順番や方法を見ることができます。 SQLが遅いときは、この部分が原因になることもあります。
どれくらいの行を処理する見込みか
行とは、表の中の1件分のデータです。 会員テーブルなら、1人分の会員情報が1行になります。
実行計画には、どれくらいの行を処理する見込みかが出ることがあります。 この見込みが大きいほど、時間がかかりやすくなります。
ただし、見込みは必ず正しいとは限りません。 見込みと実際の件数が大きくずれると、SQLが遅くなることがあります。
並べ替えや集計に時間がかかっていないか
SQLでは、データを並べ替えたり、合計したり、件数を数えたりすることがあります。 これらの処理は、データ量が多いと時間がかかることがあります。
実行計画では、SortやAggregateのような表示で分かる場合があります。 Sortは並べ替え、Aggregateは集計を意味します。
初心者のうちは、細かい言葉をすべて覚える必要はありません。 「並べ替えや集計は時間がかかることがある」と覚えておくと十分です。
実行計画の基本的な見方
実行計画の見方は、最初はむずかしく見えます。 ただし、見る順番を決めると理解しやすくなります。
まずは全体の流れを見ます。 次に、データの読み取り方法、処理する行数、コストを確認します。
まずは処理の流れを見る
実行計画では、SQLがどの順番で処理されるかを確認します。 上から下に読むものもあれば、下から上に読むものもあります。
また、実行計画は親子関係のような形で表示されることがあります。 字下げされている部分は、別の処理の中で使われる子どもの処理のように見ると分かりやすいです。
たとえば、先に表を読み、その結果を別の処理へ渡すような流れです。 最初は細かい順番まで覚えようとせず、「どの処理がどの処理につながっているか」を見るだけでも十分です。
次にデータの読み取り方法を見る
次に見るのは、データをどう読んでいるかです。 表を全部読んでいるのか、インデックスを使って探しているのかを確認します。
表を全部読む処理は、Table ScanやSeq Scanと表示されることがあります。 インデックスを使う処理は、Index Scanと表示されることがあります。
Table ScanやSeq Scanは、表を広く読む処理です。 Index Scanは、インデックスを使って探す処理です。
処理する行数を見る
次に、処理する行数を見ます。 多くの行を処理している場所は、SQLが遅くなる原因になりやすいです。
実行計画では、rowsのような名前で表示されることがあります。 rowsは、処理する行数の見込みです。
コストが高い場所を見る
コストとは、データベースが考える処理の重さの目安です。 料金の意味ではありません。
コストが高い場所は、時間がかかりやすい処理の可能性があります。 ただし、コストは時間そのものではありません。
そのため、コストだけで判断するのではなく、行数や実行時間もあわせて見ることが大切です。
想定外の全件検索がないか見る
全件検索とは、表の中のデータを最初から最後まで読むことです。 データが少ないときは問題になりにくいです。
しかし、データが多い表で全件検索が起きると、SQLが遅くなることがあります。 実行計画でTable ScanやSeq Scanが出ているときは、なぜそうなっているかを確認します。
ただし、全件検索が必ず悪いわけではありません。 小さい表や、大量のデータを読む必要がある場合は、全件検索の方が自然なこともあります。
実行計画でよく出る用語
実行計画には、英語の用語が多く出てきます。 ここでは、初心者がよく見る言葉をかんたんに説明します。
すべてを暗記する必要はありません。 まずは、データをどう読んでいるか、どう結合しているかを見られれば大丈夫です。
Table Scan・Seq Scanとは
Table ScanやSeq Scanとは、表の中のデータを順番に読んでいく処理です。 かんたんに言うと、表を全体的に見る方法です。
データ量が多いと時間がかかることがあります。 ただし、小さい表では問題にならないこともあります。
Index Scanとは
Index Scanとは、インデックスを使ってデータを探す処理です。 本の索引を使って目的のページを探すイメージです。
条件に合うデータが少ないときは、速くなりやすいです。 一方で、大量のデータを読む場合は、必ず速いとは限りません。
Nested Loopとは
Nested Loopとは、データを1件ずつ見ながら別の表と照らし合わせる結合方法です。 少ない件数をつなげるときに向いていることがあります。
ただし、件数が多いと何度も探すことになり、時間がかかることがあります。 SQLが遅いときは、Nested Loopで大量のデータを処理していないかを見ることがあります。
Hash Joinとは
Hash Joinとは、データを照らし合わせるための結合方法の一つです。 大量のデータを結合するときに使われることがあります。
初心者は、まず「大量データの結合で使われることがある方法」と覚えるとよいです。 細かい仕組みまで最初から覚える必要はありません。
Merge Joinとは
Merge Joinとは、並び順をそろえたデータ同士を結合する方法です。 データがきれいに並んでいると、効率よく処理できることがあります。
ただし、先に並べ替えが必要になると、その分だけ時間がかかる場合もあります。 実行計画では、Sortと一緒に出てくることがあります。
Sortとは
Sortとは、データを並べ替える処理です。 たとえば、日付順や金額順に並べるときに使われます。
データ量が少なければ問題になりにくいです。 しかし、大量のデータを並べ替えると時間がかかることがあります。
Filterとは
Filterとは、条件に合うデータだけを残す処理です。 たとえば、「東京都の会員だけ」「1万円以上の注文だけ」のように絞り込みます。
Filterが多いから悪いとは限りません。 ただし、たくさんのデータを読んだあとに絞っている場合は、時間がかかることがあります。
実行計画のコストとは
実行計画のコストとは、データベースが考える処理の重さの目安です。 コストという言葉が出ますが、お金の意味ではありません。
コストが高い処理は、時間がかかりやすい可能性があります。 ただし、コストだけでSQLの良し悪しを決めるのは避けた方がよいです。
コストは処理の重さを表す目安
コストは、データベースが「この処理はどれくらい大変そうか」と見積もった数字です。 表を読む量や、結合の仕方などをもとに計算されます。
数字が大きいほど、時間がかかりやすい処理だと判断されていることが多いです。 ただし、データベースの種類によって意味や見え方は変わります。
コストは実行時間そのものではない
コストは、秒数ではありません。 「コスト100だから100秒かかる」という意味ではありません。
実際の時間は、サーバーの性能、データ量、他の処理の混み具合などでも変わります。 そのため、コストは目安として見ます。
コストだけで良し悪しを決めない
コストが低くても、実際には遅いことがあります。 反対に、コストが高く見えても、問題にならないこともあります。
大切なのは、コスト、行数、読み取り方法、実行時間をあわせて見ることです。 実行計画は、1つの数字だけを見るものではありません。
実行計画のrowsとは
rowsとは、処理する行数の見込みです。 行とは、表の中の1件分のデータを指します。
たとえば、会員が1万人いれば、会員テーブルには1万行のデータがあります。 rowsを見ると、データベースが何行くらい処理すると考えているかが分かります。
rowsは処理する行数の見込み
rowsは、実際に必ずその件数を読むという意味ではありません。 データベースが予想した件数です。
この予想がだいたい合っていれば、適切な実行計画になりやすいです。 反対に、大きくずれると、よくない道順を選ぶことがあります。
見込みと実際の件数がずれるとSQLが遅くなりやすい
たとえば、実際には100万件あるのに、データベースが100件くらいだと思っている場合があります。 この場合、軽い処理だと判断して、合わない実行計画を選ぶことがあります。
このずれの原因になるものの一つが、統計情報です。 統計情報とは、データベースが「この表にはどれくらいデータがあるか」を知るための情報です。
たとえば、会員が何人いるか、どの値が多いかを判断する材料になります。 統計情報が古いと、実行計画が実際のデータに合わなくなることがあります。
SQLが遅いときに実行計画で見るポイント
SQLが遅いときは、実行計画を見ることで原因の候補を探せます。 特に、全件検索、インデックス、結合、並べ替え、統計情報を確認します。
はじめから完璧に読む必要はありません。 まずは「大量のデータを読んでいないか」を見るだけでも十分です。
全件検索になっていないか
大きなテーブルで全件検索が起きていると、SQLが遅くなることがあります。 Table ScanやSeq Scanが出ている場合は、確認する価値があります。
ただし、全件検索が必ず悪いわけではありません。 条件に合うデータが多い場合や、小さいテーブルでは自然なこともあります。
インデックスが使われているか
検索条件に合ったインデックスがあると、データを探しやすくなることがあります。 実行計画でIndex Scanが出ていれば、インデックスが使われている可能性があります。
ただし、インデックスがあるのに使われない場合もあります。 条件の書き方やデータ量によって、使わない方がよいと判断されることがあるからです。
結合の順番が不自然ではないか
複数のテーブルを結合するSQLでは、結合の順番が大切です。 大量のデータを先に結合してしまうと、処理に時間がかかることがあります。
実行計画を見ると、どのテーブルを先に読んで、どの順番で結合しているかが分かります。 SQLが遅いときは、ここも確認します。
大量のデータを並べ替えていないか
Sortが出ている場合は、並べ替えが行われています。 並べ替えるデータが多いと、時間がかかることがあります。
ORDER BYやGROUP BYを使うSQLでは、並べ替えや集計が時間のかかる処理になる場合があります。 必要な並べ替えかどうかを確認するとよいです。
統計情報が古くないか
統計情報が古いと、データベースがデータ量を正しく見積もれないことがあります。 その結果、実際のデータに合わない実行計画になる場合があります。
特に、データを大量に追加、変更、削除したあとにSQLが遅くなった場合は確認する価値があります。 統計情報が実際のデータに合っているかを見ます。
統計情報が古いことが原因であれば、統計情報を更新することで改善につながる場合があります。 たとえば、OracleではDBMS_STATS、PostgreSQLやMySQLではANALYZE、SQL ServerではUPDATE STATISTICSのような方法があります。
ただし、統計情報の更新はシステム全体に影響することがあります。 実際に行うときは、管理者や担当者に確認してから進めましょう。
実行計画の取得方法
実行計画の取得方法は、使っているデータベースによって違います。 Oracle、PostgreSQL、MySQL、SQL Serverでは、使うコマンドや画面が少しずつ異なります。
ここでは、初心者向けに大まかな考え方を紹介します。 実際に使うときは、利用している環境のルールに合わせて確認してください。
Oracleで実行計画を取得する方法
Oracleでは、EXPLAIN PLANという方法で実行計画を確認できます。 EXPLAIN PLANとは、SQLをどのように処理する予定かを表示するための命令です。
また、SQL Developerという画面ツールから確認できる場合もあります。 SQL Developerとは、Oracleのデータベースを操作するためのツールです。
Oracleの実行計画では、TABLE ACCESS FULL、INDEX RANGE SCAN、NESTED LOOPSなどの表示が出ることがあります。 まずは、表を広く読んでいるのか、インデックスを使っているのかを見るとよいです。
PostgreSQLで実行計画を取得する方法
PostgreSQLでは、EXPLAINを使って実行計画を確認できます。 PostgreSQLとは、よく使われているデータベースの一つです。
実際の実行結果に近い情報を見たい場合は、EXPLAIN ANALYZEを使うことがあります。 EXPLAIN ANALYZEとは、実際にSQLを動かして、かかった時間も見る命令です。
ただし、EXPLAIN ANALYZEは実際にSQLを実行します。 更新や削除をするSQLでは、十分に注意して使う必要があります。
PostgreSQLでは、Seq Scan、Index Scan、Nested Loop、Hash Joinなどがよく出ます。 初心者は、Seq ScanとIndex Scanの違いから見ると理解しやすいです。
MySQLで実行計画を取得する方法
MySQLでは、EXPLAINを使って実行計画を確認できます。 MySQLとは、Webサービスなどでよく使われるデータベースです。
MySQLの実行計画では、type、key、rows、Extraなどの項目を見ることがあります。 keyには、使われたインデックスが表示されることがあります。
rowsは、処理する行数の見込みです。 Extraには、Using whereやUsing filesortなどの補足情報が出ることがあります。
また、MySQL 8.0以降では、EXPLAIN ANALYZEを使える場合があります。 EXPLAIN ANALYZEでは、SQLを実際に動かして、実行時間や実際に処理した行数を確認できます。
ただし、EXPLAIN ANALYZEはSQLを実際に実行します。 更新や削除をするSQLに使う場合は、事前に十分確認することが大切です。
SQL Serverで実行計画を取得する方法
SQL Serverでは、SSMSというツールで実行計画を確認できます。 SSMSとは、SQL Serverを操作するための画面ツールです。
SQL Serverの実行計画は、図で表示されることがあります。 どの処理にどれくらいの負荷があるかを見やすい形で確認できます。
Clustered Index Scan、Index Seek、Nested Loops、Hash Matchなどの表示が出ることがあります。 まずは、広く読んでいるのか、インデックスで探しているのかを見るとよいです。
データベースごとの実行計画の違い
実行計画の考え方は、どのデータベースでも大きくは同じです。 ただし、表示される言葉や取得方法は異なります。
そのため、記事や本で学ぶときは、どのデータベースの説明なのかを確認すると理解しやすくなります。 Oracleの説明をMySQLにそのまま当てはめると、言葉が違って見えることがあります。
Oracleの実行計画
Oracleの実行計画では、TABLE ACCESS FULLやINDEX RANGE SCANなどの表示が出ます。 TABLE ACCESS FULLは、表を広く読む処理です。
Oracleでは、コストや行数、結合方法を見ることが大切です。 特に、想定外の全件検索や結合の順番を確認します。
PostgreSQLの実行計画
PostgreSQLでは、Seq ScanやIndex Scanなどがよく出ます。 Seq Scanは、表を順番に読む処理です。
EXPLAIN ANALYZEを使うと、実際の実行時間や実際の行数も確認できます。 ただし、実際にSQLが動くため、更新や削除のSQLでは注意が必要です。
MySQLの実行計画
MySQLでは、EXPLAINの結果を表の形で確認することが多いです。 type、key、rows、Extraなどを見ます。
特に、keyにインデックス名が出ているか、rowsが多すぎないかを確認します。 Using filesortが出ている場合は、並べ替えが重くなっていないかを見ることがあります。
MySQL 8.0以降では、EXPLAIN ANALYZEによって、より実際の処理に近い情報を確認できる場合があります。 通常のEXPLAINとあわせて使い分けると、見込みと実際の差を見つけやすくなります。
SQL Serverの実行計画
SQL Serverでは、図で実行計画を見られることがあります。 視覚的に処理の流れを確認しやすいのが特徴です。
Index Seek、Index Scan、Table Scanなどの違いを見ると、データの探し方が分かります。 また、どの処理に負荷がかかっているかも確認できます。
実行計画を見るときの注意点
実行計画はとても便利ですが、見方を間違えると判断を誤ることがあります。 初心者は、ひとつの表示だけで決めつけないことが大切です。
SQLの目的、データ量、実行時間もあわせて確認しましょう。 実行計画は、原因を探すための地図のようなものです。
実行計画だけで原因を決めつけない
実行計画に時間がかかりそうな処理が出ていても、それだけで原因とは限りません。 実際には別の場所で時間がかかっていることもあります。
実行時間、データ件数、サーバーの状態もあわせて見ることが大切です。 実行計画は、原因を探すための手がかりとして使います。
実際に使う環境とテスト用の環境では結果が変わることがある
本番環境とは、実際に利用者が使っている場所です。 開発環境とは、テストや作業をするための場所です。
本番環境と開発環境では、データ量が違うことがあります。 そのため、同じSQLでも実行計画が変わる場合があります。
インデックスを増やせば必ず速くなるわけではない
インデックスは、検索を速くする助けになることがあります。 しかし、増やせば増やすほどよいわけではありません。
インデックスが多すぎると、データを追加したり更新したりするときの負担が増えることがあります。 必要な場所に、適切に作ることが大切です。
データの件数やSQLの目的もあわせて見る
同じ実行計画でも、データ件数によって意味が変わります。 小さい表の全件検索は問題になりにくいです。
一方で、何百万件もある表の全件検索は時間がかかることがあります。 実行計画を見るときは、対象のデータ量も確認しましょう。
実行計画と似た言葉との違い
実行計画には、似た言葉がいくつかあります。 ここでは、初心者が混同しやすい言葉との違いを整理します。
実行計画と実行時間の違い
実行計画は、SQLをどのように処理するかを示す計画です。 実行時間は、実際にSQLの処理にかかった時間です。
つまり、実行計画は「道順」です。 実行時間は「実際にかかった時間」です。
実行計画とSQLチューニングの違い
SQLチューニングとは、SQLをより速く、より負担が少ない形に見直すことです。 チューニングとは、調整するという意味です。
実行計画は、SQLチューニングのために見る情報の一つです。 実行計画を見ることで、どこを直せばよいかを考えやすくなります。
SQLの実行計画とビジネスの実行計画書の違い
SQLの実行計画は、データベースがSQLを処理する手順です。 一方、ビジネスの実行計画書は、仕事や事業を進めるための計画書です。
同じ「実行計画」という言葉でも、意味が違います。 この記事で扱うのは、SQLやデータベースの実行計画です。
初心者が間違えやすいポイント
実行計画は、慣れるまで分かりにくく感じやすいです。 しかし、よくある間違いを知っておくと読みやすくなります。
コストが低ければ必ず速いと思ってしまう
コストは処理の重さの目安です。 実行時間そのものではありません。
そのため、コストが低くても実際には遅いことがあります。 反対に、コストが高くても問題にならないこともあります。
Index Scanなら必ずよいと思ってしまう
Index Scanは、インデックスを使ってデータを探す処理です。 多くの場合、効率よく探す助けになります。
ただし、大量のデータを読む場合は、Index Scanが必ず速いとは限りません。 状況によっては、表を広く読んだ方がよい場合もあります。
Seq ScanやTable Scanをすべて悪いものと思ってしまう
Seq ScanやTable Scanは、表を広く読む処理です。 大きな表では時間がかかることがあります。
しかし、小さい表では問題にならないことも多いです。 また、ほとんどのデータを読む場合は、自然な処理になることもあります。
取得した実行計画だけを見て判断してしまう
実行計画は、判断材料の一つです。 それだけを見て、すぐに原因を決めるのは避けましょう。
実際の実行時間、データ件数、SQLの目的もあわせて見ることが大切です。 複数の情報を見れば、より正しく判断しやすくなります。
実行計画に関するよくある質問
実行計画とは何ですか？
実行計画とは、データベースがSQLをどのような順番で処理するかを示した計画です。 SQLを処理するための道順のようなものです。
SQLの実行計画とは何ですか？
SQLの実行計画とは、SQLを実行するときにデータベースが作る処理の進め方です。 どの表を読むか、どの条件で絞るか、どの順番で結合するかなどが分かります。
実行計画を見ると何が分かりますか？
どのテーブルを読むか、インデックスを使っているか、どれくらいの行を処理するかが分かります。 また、結合や並べ替えの処理も確認できます。
SQLが遅いときは実行計画のどこを見ればよいですか？
まずは、全件検索になっていないかを見ます。 次に、処理する行数、インデックス、結合、並べ替えを確認します。
実行計画のコストとは何ですか？
コストとは、データベースが考える処理の重さの目安です。 実行時間そのものではありません。
実行計画のrowsとは何ですか？
rowsとは、処理する行数の見込みです。 データベースが「これくらいの件数を処理しそう」と予想した数字です。
EXPLAIN ANALYZEとは何ですか？
EXPLAIN ANALYZEとは、SQLを実際に動かして、実行計画と実際の時間を確認する方法です。 PostgreSQLやMySQLなどで使える場合があります。
ただし、SQLを実際に実行するため、更新や削除をするSQLでは注意が必要です。 使う前に、対象のSQLと環境を確認しましょう。
実行計画は初心者でも見た方がよいですか？
SQLが遅い原因を調べたい場合は、初心者でも少しずつ見られるようになると役立ちます。 最初は、全件検索、行数、インデックスの3つを見るだけでも十分です。
まとめ：SQLの実行計画とはSQLが遅い原因を調べるための手がかり
SQLの実行計画とは、データベースがSQLをどのような順番で処理するかを示した計画です。 かんたんに言うと、SQLを処理するための道順です。
実行計画を見ると、どのテーブルを読むか、インデックスを使っているか、どれくらいの行を処理するかが分かります。 SQLが遅いときは、原因を探す手がかりになります。
初心者は、まず全件検索、行数、コスト、インデックス、結合の5つを見るとよいです。 実行計画だけで決めつけず、実行時間やデータ件数もあわせて確認しましょう。