MySQLの詳細な分析で使用法と結果を説明します

序文

日常業務では、実行に時間のかかる SQL ステートメントを記録するために、スロークエリを実行することがあります。これらの SQL ステートメントを見つけても、作業が完了したわけではありません。SQL ステートメントがインデックスを使用しているかどうか、および完全なテーブルスキャンが実行されているかどうかを確認するために、explain コマンドを使用してこれらの SQL ステートメントの実行プランを表示することがよくあります。これは、explain コマンドで表示できます。したがって、MySQL のコストベースのオプティマイザについて深く理解でき、また、オプティマイザが考慮する可能性のあるアクセス戦略や、SQL ステートメントを実行するときにオプティマイザが採用すると予想される戦略に関する多くの詳細も取得できます。 (QEP: sql は実行プランクエリ実行プランを生成します)

mysql> explain select * from servers;
+----+-------------+---------+-------+---------------+-------+-------+------+------+
| id | select_type | テーブル | タイプ | possible_keys | key | key_len | ref | 行 | 追加 |
+----+-------------+---------+-------+---------------+-------+-------+------+------+
| 1 | SIMPLE | サーバー | すべて | NULL | NULL | NULL | NULL | 1 | NULL |
+----+-------------+---------+-------+---------------+-------+-------+------+------+
セット内の1行（0.03秒）

1. EXPLAINの紹介

EXPLAIN キーワードを使用すると、オプティマイザーをシミュレートして SQL クエリステートメントを実行し、MySQL が SQL ステートメントをどのように処理するかを知ることができます。クエリステートメントまたはテーブル構造のパフォーマンスのボトルネックを分析します。 explain を通じて、次の情報を取得できます。

表の読み順
データ読み取り操作の操作タイプ
使用できるインデックス
実際に使用されているインデックスはどれですか?
テーブル間の参照
オプティマイザによって各テーブルにクエリされる行数

使用法: explain + sql ステートメント。含まれるフィールドは次のとおりです

2. 実行計画の各フィールドの意味

2.1 id

IDは同じで、実行順序は上から下です

idが異なります。サブクエリの場合はid番号が増加します。id値が大きいほど優先度が高くなり、早く実行されます。

同じ ID または異なる ID が同時に存在する場合、同じ ID はグループとみなされます。実行は同じグループ内で上から下へ行われ、最も大きい ID を持つグループが最初に実行されます。

2.4型

Type は、クエリで使用されるタイプを示します。type に含まれるタイプは次のとおりです。

システム > const > eq_ref > ref > 範囲 > インデックス > すべて

システムテーブルには、レコードの行が 1 つだけあります (システムテーブルと同じ)。これは、const 型の特別な列であり、通常は表示されません。無視することもできます。
const はインデックスが 1 回見つかることを意味し、const は主キーまたは一意のインデックスを比較するために使用されます。 1行のデータのみが一致するため、非常に高速です。主キーを where リストに入れると、MySQL はクエリを定数に変換できます。
eq_ref 一意のインデックススキャン。各インデックスキーに対して、テーブル内に一致するレコードが 1 つだけ存在します。主キーまたは一意のインデックススキャンによく使用されます
ref 非一意インデックススキャン。単一の値に一致するすべての行を返します。これは本質的にはインデックスアクセスです。単一の値に一致するすべての行を返します。ただし、複数の条件に該当する行が見つかる可能性があるため、検索とスキャンの組み合わせとして考える必要があります。
range は、インデックスを使用して行を選択し、指定された範囲内の行のみを取得します。キー列には、使用されているインデックスが表示されます。これは通常、where ステートメントで between、<、>、in などを使用するクエリです。この範囲スキャンインデックスは、インデックス全体をスキャンせずに、インデックス内の 1 つのポイントから開始して別のポイントで終了するだけでよいため、完全なテーブルスキャンよりも優れています。
インデックスフルインデックススキャン。インデックスと All の違いは、インデックスタイプではインデックスツリーのみを走査することです。通常、インデックスファイルはデータファイルよりも小さいため、これは ALL よりも高速です。 (つまり、all と Index はどちらもテーブル全体を読み取りますが、index はインデックスから読み取り、all はハードディスクから読み取ります)
フルテーブルスキャンはテーブル全体をスキャンして一致する行を検索します

2.5 possible_keys と key

possible_keys は、このテーブルに適用できる可能性のあるインデックス（1 つ以上）を示します。クエリに関係するフィールドにインデックスが存在する場合、そのインデックスはリストされますが、クエリによって実際に使用されない可能性があります。

キーによって実際に使用されるインデックス。NULL の場合、インデックスは使用されません。 (考えられる理由としては、インデックスがない、またはインデックスに障害があるなど)

2.6 キーの長さ

インデックスで使用されるバイト数を示します。この列は、クエリで使用されるインデックスの長さを計算するために使用できます。長さが短いほど、精度が損なわれずに済みます。

2.7行

テーブルの統計とインデックスの選択に基づいて、必要なレコードを見つけるために必要な行数を大まかに見積もります。つまり、行数が少ないほど良いということです。

2.8 追加

2.8.1 ファイルソートの使用

これは、MySQL がテーブル内のインデックスの順序でデータを読み取るのではなく、外部インデックスを使用してデータを並べ替えることを意味します。インデックスを使用して実行できない MySQL でのソート操作は、「ファイルソート」と呼ばれます。

2.8.2 一時的使用

一時テーブルは中間結果を保存するために使用されます。MySQL はクエリ結果をソートするときに一時テーブルを使用します。一般的に、並べ替えやグループ化クエリで使用されます。

2.8.3 インデックスの使用

対応する選択操作でカバーインデックスが使用され、テーブルのデータ行へのアクセスが回避されることを示します。これは効率的です。 where の使用が同時に出現する場合は、インデックスがインデックスキー値の検索を実行するために使用されることを意味します。where の使用が同時に出現しない場合は、インデックスが検索を実行するのではなく、データを読み取るために使用されることを意味します。

2.8.4 結合バッファの使用

接続キャッシュが使用されていることを示します。たとえば、クエリを実行すると、複数テーブルの結合の数が非常に多くなるため、構成ファイルで結合バッファを増やします。

要約する

MySQL explain の使用法と結果の詳細な分析に関するこの記事はこれで終わりです。MySQL explain の使用法と結果に関するより関連性の高いコンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: