Explain の用途は何ですか Explain が SQL ステートメント MySQL# とともに使用される場合## オプティマイザからのSQL実行に関する情報が表示されます。つまり、MySQL は、テーブルを結合する方法やテーブルを結合する順序などを含めて、ステートメントをどのように処理するかを説明します。 テーブルの読み込みシーケンス SQL のクエリ タイプ 使用できるインデックスと実際に使用されるインデックス テーブル間の参照関係オプティマイザによってクエリされるテーブル内の行数...... 説明はい何を情報 Explain 実行計画には次のフィールド情報が含まれます: id、select_type、table、partitions 、type、possible_keys、key、key_len、ref、行 、filtered、Extra12 フィールド。 実行計画の詳細説明 1. id id: : であることを示します。クエリが実行中です。 select 句または操作テーブルの順序で、id の値が大きいほど優先度が高く、 が最初に実行されます。 id大まかに 3 つの状況があります: 1、id は同じです 3 つのレコードを参照 id はすべて同じです。これら 3 つのテーブルは同じ優先度を持つグループであることがわかります。実行順序は上から下です。具体的な順序はオプティマイザによって決定されます。 2、id は異なります SQL にサブクエリがある場合は、id のシーケンス番号が増加し、id の値が大きいほど優先度が高く、最初に実行されます。 3 つのテーブルが順番にネストされている場合、最も内側のサブクエリ id が最大であり、最初に実行されることがわかります。 3. 上記の 2 つは同時に存在します上記の SQL を少し変更し、サブクエリを追加して、id を見つけます 上記 2 種類が同時に存在します。同じ id を 1 つのグループに分けているため 3 つのグループがあり、同じグループ内のものは上から順に実行され、異なるグループの id の値が大きいほど、優先順位が高く、より早く実行されます。 2. select_type select_type: select クエリのタイプを示し、主にさまざまな複雑なクエリを区別するために使用されます。例: 通常のクエリ、ユニオン クエリ、サブクエリなど。 1. SIMPLE SIMPLE: 最も単純な選択クエリ ステートメントを表します。つまり、クエリにサブクエリや ユニオンが含まれていません。 交差集合と差分集合およびその他の演算。 2, PRIMARY PRIMARY: クエリ ステートメントに複雑なサブパートが含まれる場合、最も外側のクエリは PRIMARY とマークされます。 。 3. SUBQUERY SUBQUERY: select または where リストにサブクエリが含まれている場合の場合、サブクエリは SUBQUERY とマークされます。 4. DERIVED DERIVED: from 句に含まれるサブクエリの選択を表します。 from リストに含まれるものは、derived としてマークされます。 5, UNION UNION: select ステートメントが union の後にある場合、 union としてマークされます。union が from 句のサブクエリに含まれている場合、外側の select は ## としてマークされます。 ＃派生＃＃＃。 6. UNION RESULT UNION RESULT: union の一時テーブルからのデータの読み取りを表し、table 列の は、最初と 4 番目の select の結果を使用して union 操作が実行されることを示します。 3. table クエリされたテーブル名は必ずしも実際のテーブルであるとは限りません。別名を表示するための別名があるか、一時テーブルである可能性があります。上記の # のように。##DERIVED、 など。 4. パーティション クエリ時に一致するパーティション情報 (非パーティション テーブルの場合、値は NULL)、パーティション テーブルのクエリの場合 partitionsパーティション テーブルにヒットしたパーティションを表示します。 5. type type: クエリで使用される型は何ですか? SQL## では非常に重要な要素です。 # 最適化。重要な指標であり、パフォーマンスは最良から最悪まで次のとおりです: system>const>eq_ref>ref> ;ref_or_null>index_merge>unique_subquery>index_subquery>range>index >ALL ##1, system system: テーブルにレコードが 1 行しかない場合 (システム テーブル)、データ量は非常に少なく、多くの場合ディスク IO は必要なく、速度は非常に高速です。 2、const const: primary key 主キーまたは unique であることを示します。クエリ中にヒットしました。 一意のインデックス、つまり連結部分は定数 (const) 値です。このタイプのスキャンは非常に効率的で、返されるデータの量が少なく、非常に高速です。 3. eq_ref eq_ref: 主キー primary key または unique key をヒットします。クエリインデックス中、type は eq_ref です。 4、ref ref: eq_ref とは異なり、ref は非ユニークな性的インデックスを使用すると、条件を満たす行が多数見つかります。 5、ref_or_null ref_or_null: この接続タイプは ref に似ていますが、異なる点は、MySQL が追加でNULL 値の行を含むアイテムを検索します。 6.index_merge index_merge: インデックス マージ最適化メソッドが使用され、クエリで 3 つ以上のインデックスが使用されます。 7. unique_subquery unique_subquery: 次の IN サブクエリを置き換えると、サブクエリは一意のセットを返します。 value IN (SELECT primary_key FROM single_table WHERE some_expr)ログイン後にコピー 8、index_subquery index_subquery: unique_subquery とは異なり、一意でないインデックスに使用され、重複した値を返します。 value IN (SELECT key_column FROM single_table WHERE some_expr)ログイン後にコピー 9, range range: インデックスを使用して行を選択し、指定された範囲内の行のみを取得します。簡単に言うと、インデックス付きフィールドに対して指定された範囲内のデータを取得することです。 where ステートメントでは、bettween...and、<、>、<= を使用します。 、in およびその他の条件付きクエリ type はすべて range です。 インデックスが設定されているフィールドに対して範囲検索 type のみを実行するのは range です。 10、index index: Index と ALL は実際にテーブル全体を読み取ります。違いは、index はインデックス ツリーを走査することによって読み取られるのに対し、ALL はハード ディスクから読み取られることです。 11、ALL ALL: 一致する行を見つけるためにテーブル全体が走査されますが、パフォーマンスは最悪になります。 6. possible_keys possible_keys: MySQL のどのインデックスを使用すればテーブル内で検索できるかを示します。レコードでは、クエリに関係するフィールドにインデックスが存在すると、そのインデックスがリストされます ただし、このインデックスは、最終的にデータをクエリするときに使用されるインデックス であるとは限りません。詳細については、上記の例を参照してください。 7. key key: possible_keys とは異なり、key はクエリで実際に使用されるインデックスです。インデックスは使用されないため、NULL として表示されます。詳細については、上記の例を参照してください。 type が index_merge の場合、複数のインデックスが表示される場合があります。 8. key_len key_len: クエリで使用されるインデックスの長さ (バイト数) を示します。長さは短いほど良いです。 単一列インデックスの場合、インデックス全体の長さを含める必要があります。複数列インデックスの場合、すべての列を使用できるわけではなく、クエリで使用される実際の列計算する必要があります。 注: key_len は、where 条件で使用されるインデックスの長さのみを計算します。インデックスが並べ替えやグループ化に使用される場合でも、 key_len に計算されます。 9. ref ref: 一般的なものは次のとおりです: const、func、null、フィールド名。 定数等価クエリの場合は const が表示されます 関連クエリの場合は対応する関連テーブルの 関連フィールド クエリ条件に expression、function が使用されている場合、または条件列が内部で暗黙的な変換を受ける場合、func# と表示される場合があります。 ##その他の状況null ##10. rows rows: に基づくテーブルの統計情報とインデックスの使用状況、必要なレコードを見つけるために読み取る必要がある行数の推定。 これは、SQL のパフォーマンスを評価するための重要なデータです。mysqlスキャンする必要がある行数は、SQL## の非常に直感的な表示です。 # パフォーマンス。良くも悪くも、通常は rows 値が小さいほど優れています。 11.filtered filteredこれは、テーブル内の条件を満たすレコード数の割合を示すパーセンテージ値です。簡単に言うと、このフィールドは、ストレージ エンジンから返されたデータをフィルター処理した後に条件を満たす残りのレコードの割合を表します。 MySQL.5.7 バージョンより前のバージョンでは、filtered を表示したい場合は、explain extended コマンドを使用する必要があります。 MySQL.5.7 以降、デフォルトでは explain は partitions と filtered の情報を直接表示します。 12. 追加 追加: 他の列での表示には適さない情報、多くは Explain に追加情報が表示されます。 Extraフィールドに表示されます。 1. インデックスの使用 インデックスの使用: 対応する select 操作でカバー インデックスを使用します。簡単に言うと、クエリ対象の列がインデックスでカバーされており、カバーインデックスを使用するとクエリ速度が非常に速くなり、最適化の理想的な状態となります。 カバリング インデックスとは何ですか?A SQL はインデックスを通じて返されるだけです。クエリする必要があるデータ (1 つまたは複数のフィールド) には、セカンダリ インデックスを使用して、主キーを見つけた後、主キーを使用してデータ行全体をクエリします (select *)。 注: カバリングインデックスを使用したい場合は、select のときに必須フィールドのみを取り出します。select ** はできません。このフィールドのインデックスが作成されました。 2. whereWhere の使用: クエリ中に使用可能なインデックスが見つからないため、where でフィルターされます。条件 必要なデータを取得しますが、where ステートメントを含むすべてのクエリに Using where が表示されるわけではないことに注意してください。 3. 一時的な使用一時的な使用: クエリ後の結果を一時テーブルに保存する必要があることを示します。通常、次の場合に使用されます。クエリの並べ替えまたはグループ化。 4. filesort の使用filesort の使用: インデックス、つまり ORDER を使用して並べ替え操作を完了できないことを示します。 BY フィールドのインデックスがないため、通常、このような SQL を最適化する必要があります。 ORDER BY フィールドにインデックスがある場合は、カバー インデックスが使用され、実行よりもはるかに高速になります。 5. 結合バッファの使用結合バッファの使用: 結合テーブルをクエリするとき、テーブルの結合条件がインデックスを使用しない場合、中間結果を保存するには接続バッファが必要です。 6. 不可能な where 不可能な where: これは、間違った where ステートメントを使用していることを意味します。条件に一致する行。 7. テーブルは使用されていませんテーブルは使用されていません: クエリ ステートメントに FROM 句がありません。または、 FROM DUAL 句があります。 Extra 列には多くの情報があるため、ここでは 1 つずつ列挙しません。詳細については、MySQL 公式ドキュメントを参照してください。 https://dev.mysql.com /doc/ref… 概要主要な列: possible_keys: 使用可能な場合があります インデックスの名前。ここでのインデックス名は、インデックスの作成時に指定されたインデックスのニックネームです。インデックスにニックネームがない場合は、デフォルトでインデックスの最初の列の名前が表示されます (この例では、「firstname」)。デフォルトのインデックス名の意味は、多くの場合明らかではありません。 key: MySQL が実際に使用するインデックスの名前を示します。空 (または NULL) の場合、MySQL はインデックスを使用しません。 key_len: インデックスの使用されている部分の長さ (バイト単位) ref: リストが定数 (const) または特定のテーブルのフィールド (結合の場合) によって (キーによって) フィルターされるかどうか ; rows: MySQL が考慮する内容正しい結果を見つける前にスキャンする必要があるレコードの数。明らかに、ここでの理想的な数は 1 です。 推奨学習: 「mysql ビデオ チュートリアル 」
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
