MySQL での Explain の使用法の概要 (詳細)

不言
リリース: 2019-01-08 09:28:23
転載
6284 人が閲覧しました


この記事は、MySQL での Explain の使用法 (詳細) をまとめたものです。必要な方は参考にしていただければ幸いです。それはあなたの役に立つでしょう。

実行計画 (クエリ実行計画)

構文

explain select * from table
ログイン後にコピー

explain

expain の列には 10 列の情報があります。
は、id、select_type、table、type、partitions、 possible_keys、key、key_len、ref、rows、Extra です。これらのフィールドの出現について考えられる説明は次のとおりです。 ID

SQL の実行順序の識別。SQL は大きいものから小さいものへ実行されます。#1 ID が同じ場合、実行順序は上から下へ

2. サブクエリの場合、ID の値が大きいほど優先度が高く、最初に実行されます。値が同じ場合はグループとみなし、上から下へ順番に実行できます。すべてのグループの中で、ID 値が大きいほど優先順位が高く、より早く実行されます。 select_type

クエリ内の各選択句のタイプを示します

1: 単純な SELECT、UNION、またはサブクエリは実用的ではありません。

2. プライマリ: 最も外側の SELECT。

3. UNION: 2 番目の層では、SELECT の後に UNION が使用されます。

4. DEPENDENT UNION: UNION ステートメントの 2 番目の SELECT は外部サブクエリに依存します。

5. UNION の結果: UNION の結果。

6. サブクエリ: サブクエリの最初の SELECT。

7. 依存サブクエリ: サブクエリの最初の SELECT は外部クエリに依存します。

8. DERIVED: 派生テーブルの SELECT (FROM 句のサブクエリ)

9. MATERIALIZED: マテリアライズド サブクエリ

#10. UNCACHEABLE SUBQUERY: 結果のサブクエリをキャッシュできません外側のクエリ

#11 の各行に対して再計算する必要があります。 UNCACHEABLE UNION: UNION は、キャッシュ不可能なサブクエリ テーブル

3 の 2 番目以降の選択に属します。

出力行によって参照されるテーブルの名前。これは、次の値のいずれかにすることもできます:

MM

,N

,

    ...
  • >: この行は、ID 値 M と ID 値 N の結合を参照します。 N>: この行は、この行の派生テーブルの結果 ID に使用される値 N を参照します。たとえば、派生テーブルは FROM 句のサブクエリ

  • N
  • > から取得できます。 ID 値 N

    を持つ行に対するマテリアライズされたサブクエリの結果。 type
  • は、MySQL が必要な行を検索する方法を表します。テーブル。「アクセス タイプ」とも呼ばれます。 一般的に使用される型は次のとおりです: NULL、system、const、eq_ref、ref、range、index、ALL (左から右へ、パフォーマンスは最悪から最高) 次のリストでは、最適な型から順に説明します。最悪のタイプの接続タイプ

  • NULL

    MySQL は最適化プロセス中にステートメントを分解し、実行中にテーブルやインデックスにアクセスする必要さえありません。インデックス列からの最小値の取得は、個別のインデックス検索が完了することで実行できます。

    system

    このテーブルには行が 1 つだけあります (例: システム テーブル)。これは const 結合タイプの特殊なケースです。


    const

    テーブルには一致する行が 1 つだけあり、クエリの先頭で読み取られます。行が 1 つしかないため、残りのオプティマイザはこの行の列の値を定数として扱うことができます。 const テーブルは一度だけ読み取られるため、非常に高速です。

    SELECT * FROM tbl_name WHERE primary_key=1;
    SELECT * FROM tbl_name WHERE primary_key_part1=1 AND primary_key_part2=2;
    ログイン後にコピー

    eq_ref

    前のテーブルの行の組み合わせごとに、テーブルから 1 行を読み取ります。 system タイプと const タイプに加えて、これが最適な接続タイプです。これは、結合でインデックスのすべての部分が使用され、インデックスが PRIMARY KEY インデックスまたは UNIQUE NOT NULL インデックスである場合に使用されます。

    SELECT * FROM ref_table,other_table
      WHERE ref_table.key_column=other_table.column;
    
    SELECT * FROM ref_table,other_table
        WHERE ref_table.key_column_part1=other_table.column
        AND ref_table.key_column_part2=1;
    ログイン後にコピー

    ref

    上記の表の接続一致条件、つまり、インデックス列の値を検索するためにどの列または定数が使用されるかを示します

    fulltext

    FULLTEXT インデックスを使用して結合を実行します。

    ref_or_null

    SELECT * FROM ref_table WHERE key_column IS NULL;
    ログイン後にコピー

    index_merge

    インデックス マージ アクセス メソッドは、範囲スキャンで複数の行を取得し、その結果を 1 つにマージします。このアクセス方法は、単一のテーブルからのインデックス スキャンを結合するだけであり、複数のテーブルはスキャンしません。マージは、基礎となるスキャンのユニオン、クロス、またはクロスユニオンを生成できます。

    SELECT * FROM tbl_name WHERE key1 = 10 OR key2 = 20;
    
    SELECT * FROM tbl_name
    WHERE (key1 = 10 OR key2 = 20) AND non_key = 30;
    
    SELECT * FROM t1, t2
    WHERE (t1.key1 IN (1,2) OR t1.key2 LIKE 'value%')
    AND t2.key1 = t1.some_col;
    
    SELECT * FROM t1, t2
    WHERE t1.key1 = 1
    AND (t2.key1 = t1.some_col OR t2.key2 = t1.some_col2);
    ログイン後にコピー

    unique_subquery

    このタイプは、一部の IN サブクエリを次の形式の eq_ref に置き換えます:

    value IN (SELECT primary_key FROM single_table WHERE some_expr)
    ログイン後にコピー

    index_subquery

    この接続タイプは unique_subquery に似ています。これは IN サブクエリを置き換えますが、次の形式のサブクエリで一意でないインデックスを使用して動作します。

    value IN (SELECT key_column FROM single_table WHERE some_expr)
    ログイン後にコピー

    range

    インデックス選択を使用して、指定された範囲内の行のみを取得します OK 。出力行のキー列は、使用するインデックスを示します。最も長く使用されているキー部分を含めるには、key_len を含めます。 ref 列 NULL はこのタイプに適しています。 range キー列で定数と比較して任意の値を使用する場合、=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN、を使用できます。 LIKE 、または IN() 演算子:

    index インデックス結合タイプは、インデックス ツリーがスキャンされることを除いて、ALL と同じです。 2 つの状況があります:

    1. インデックス ツリーは、インデックスがクエリのカバー インデックスであり、テーブルに必要なすべてのデータを満たすために使用できる場合にのみスキャンされます。この場合、「追加」列には「インデックスを使用」と表示されます。インデックスのみのスキャンは、通常、テーブル データよりもサイズが小さいすべてのインデックスよりも高速です。

    2. インデックスの読み取りを使用してテーブル全体のスキャンを実行し、インデックス順にデータ行を検索します。 Uses インデックスは [Extra] 列には表示されません。 MySQL は、クエリで単一のインデックスに属するカラムのみを使用する場合に、この接続タイプを使用できます。

    ALL
    前のテーブルの行の組み合わせごとにテーブル全体のスキャンを実行します。テーブルが const としてマークされていない最初のテーブルである場合は、通常は不良であり、他のすべての場合は通常非常に不良です。通常、以前のテーブルの定数値または列値に基づいてテーブルから行を取得できるようにするインデックスを追加することで、このすべてを回避できます。この列は、MySQL がこのテーブル内の行を検索するために選択できるインデックスを示します。 MySQL がテーブル内のレコードを検索するために使用できるインデックス。クエリに関係するフィールドにインデックスが存在する場合、そのインデックスはリストされますが、

    この列は必ずしもクエリで使用されるわけではありません。 EXPLAIN 出力に表示されるテーブルの順序とは完全に独立しています。これは、 possible_keys 内の一部のキーは、生成されたテーブルの順序では実際には使用できないことを意味します。 列が NULL の場合、関連するインデックスはありません。この場合、WHERE 句をチェックして、インデックス付けに適した特定の列を参照しているかどうかを確認することで、クエリのパフォーマンスを向上させることができます。その場合は、適切なインデックスを作成し、EXPLAIN

    6 でクエリを再度確認します。 Key


    key 列には、MySQL が実際に使用することを決定したキー (インデックス) が表示されます。

    ##インデックスが選択されていない場合、キーは NULL になります。 MySQL に possible_keys カラムのインデックスの使用または無視を強制するには、クエリで FORCE INDEX、USE INDEX、または IGNORE INDEX を使用します。

    7. key_len

    は、インデックスで使用されるバイト数を示します。この列は、クエリで使用されるインデックスの長さ (値) を計算するために使用できます。 key_len によって表示されるのはインデックス フィールドです。最大可能長は、実際に使用される長さではありません。つまり、key_len はテーブルから取得されるのではなく、テーブル定義に基づいて計算されます)

    精度を損なうことなく、長さが短いほど、 ref

    は、上記の表の接続一致条件、つまり、どの列または定数が値を見つけるために使用されるかを示します。 Index column

    9 、 rows

    は、テーブル統計とインデックス選択に基づいて、必要なレコードを見つけるために読み取る必要がある行数を MySQL が推定することを示します

    10. 追加

    追加列の EXPLAIN 出力には、クエリを解決するための MySQL の追加情報が含まれています。次のリストは、この列で使用できる値を説明しています。各項目は、どのプロパティに Extra 値が表示されるかを JSON 形式の出力に示します。それらの一部には、特定のプロパティがあります。メッセージ属性として表示されるその他のテキスト

    11. パーティション (拡張子)

    クエリに一致するパーティションを記録します。この列は、PARTITIONS キーワードを使用する場合にのみ表示されます。パーティション化されていないテーブルには null が表示されます。この記事はここで終了です。MySQL について詳しくは、php 中国語 Web サイトの

    MySQL チュートリアル

    列を参照してください。 ! !

    以上がMySQL での Explain の使用法の概要 (詳細)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

関連ラベル:
ソース:segmentfault.com
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
最新の問題
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート
私たちについて 免責事項 Sitemap
PHP中国語ウェブサイト:福祉オンライン PHP トレーニング,PHP 学習者の迅速な成長を支援します!