黄舟2017-04-17 16:29:40
https://segmentfault.com/a/11... この記事を読んでください。mysql が自動的に返す実行時間は
です。
赤いのは実行時間ではないでしょうか？
クエリを最適化するためのソリューションは次のとおりです。参考にしてください。
4. クエリの最適化
4.1.EXPLAIN
MySQL では、EXPLAIN を使用して SQL 実行プランを表示できます。 使用法: EXPLAIN SELECT * FROM tb_item
4.2. 結果の説明.id
SELECT 識別子。これは SELECT クエリのシーケンス番号です。これは重要ではありません。
4.2.2.select_type
は SELECT 文の種類を示します。
1. SIMPLE
は、結合クエリとサブクエリを含まない単純なクエリを表します。
2. PRIMARY
はメインクエリ、つまり最も外側のクエリステートメントを表します。
は、接続クエリの 2 番目以降のクエリ文を表します。
UNION の 2 番目以降の SELECT ステートメントは外部クエリに依存します。
5. UNION RESULT
接続クエリの結果。
6. SUBQUERY
サブクエリの最初の SELECT ステートメント。
サブクエリの最初の SELECT ステートメントは外部クエリに依存します。
8. DERIVED
SELECT (FROM 句のサブクエリ)。
4.2.3.table
はクエリテーブルを表します。
4.2.4.type (重要)
テーブルの接続タイプを示します。
次の接続タイプは、最良から最悪の順に並べられています:
テーブルには 1 つの行しかありません。これは const 型の特殊な列であり、通常は無視できます。
2. const
データ テーブルは、最大で 1 行のデータとのみ一致するため、PRIMARY KEY または UNIQUE インデックスのクエリによく使用されます。 const が最も最適化されていることが理解できます。
MySQL マニュアルには次のように書かれています: 「前のテーブルの行の組み合わせごとに、テーブルから 1 行を読み取ります。const 型を除いて、これがおそらく最適な結合タイプです。これは次の場合に使用されます。」インデックスのすべての部分が結合で使用され、インデックスは UNIQUE または PRIMARY KEY です。」 eq_ref は、= を使用してインデックス付き列を比較するために使用できます。
クエリ条件インデックスが UNIQUE または PRIMARY KEY ではありません。 ref は、= または < または > 演算子を使用してインデックス付き列に使用できます。
この結合タイプは ref に似ていますが、NULL 値を含む行を特別に検索するための MySQL が追加されています。この結合タイプの最適化は、サブクエリを解決する際によく使用されます。
6.index_merge
この結合タイプは、インデックス マージ最適化手法が使用されることを示します。この場合、key 列には使用されるインデックスのリストが含まれ、key_len には使用されるインデックスの最長のキー要素が含まれます。
7. unique_subquery
このタイプは、IN サブクエリの ref を次の形式で置き換えます: value IN (SELECT Primary_key FROM single_table WHERE some_expr)
unique_subquery は、サブクエリを完全に置き換えることができるインデックス検索関数です。より効率的です。
8.index_subquery
この接続タイプは unique_subquery に似ています。 IN サブクエリは置換できますが、次の形式のサブクエリの一意でないインデックスに限ります: value IN (SELECT key_column FROM single_table WHERE some_expr)
9, range
1 を使用して、指定された範囲内の行のみを取得します。行を選択するためのインデックス。
10. インデックス
この結合タイプは、インデックス ツリーのみがスキャンされることを除いて、ALL と同じです。通常、インデックス ファイルはデータ ファイルよりも小さいため、これは通常 ALL よりも高速です。
11. ALL
前のテーブルの行の組み合わせごとに完全なテーブル スキャンを実行します。 (最悪のパフォーマンス)
4.2.5.possible_keys
MySQL がこのテーブル内の行を検索するために使用できるインデックスを示します。
列が NULL の場合、インデックスが使用されていないことを意味し、パフォーマンスを向上させるために列にインデックスを作成できます。
4.2.6.key
MySQL が実際に使用することを決定したキー (インデックス) を示します。インデックスが選択されていない場合、キーは NULL になります。
インデックスの使用を強制することも、インデックスを無視することもできます:
4.2.7.key_len
MySQL が使用することを決定したキーの長さを表示します。キーが NULL の場合、長さは NULL になります。
注: key_len は、MySQL が使用する実際のインデックスの長さを決定します。
4.2.8.ref
テーブルから行を選択するためにキーとともに使用される列または定数を示します。
4.2.9.rows
クエリの実行時に MySQL がチェックする必要があると考える行数を表示します。
4.2.10.Extra
この列には、MySQL がクエリを解決した方法の詳細が含まれています
区別: MySQL は、最初に一致する行を見つけた後、現在の行の組み合わせに対するさらなる行の検索を停止します。
存在しません: MySQL はクエリに対して LEFT JOIN 最適化を実行でき、LEFT JOIN 標準に一致する行を見つけた後、テーブル内の前の行の組み合わせをさらにチェックしなくなります。
各レコードの範囲チェック (インデックス マップ: #): MySQL は使用できる適切なインデックスを見つけられませんでしたが、前のテーブルの列の値がわかっている場合、一部のインデックスが使用できる可能性があることがわかりました。使用済み。
filesort の使用: MySQL では、ソートされた順序で行を取得する方法を理解するために追加のパスが必要です。
インデックスの使用: それ以上の検索を行わずに、インデックス ツリー内の情報のみを使用して実際の行を読み取ることにより、テーブルから列情報を取得します。
一時テーブルの使用: クエリを解決するには、MySQL は結果を保持する一時テーブルを作成する必要があります。
where:WHERE 句を使用すると、次のテーブルに一致する行、または顧客に送信される行を制限できます。
sort_union(...) の使用、union(...) の使用、intersect(...) の使用: これらの関数は、index_merge 結合タイプのインデックス スキャンをマージする方法を示しています。
group-by にインデックスを使用: テーブルにアクセスするインデックスを使用する方法と同様に、group-by にインデックスを使用すると、MySQL が GROUP BY または DISTINCT クエリのすべての列をクエリするために使用できるインデックスを見つけたことを意味します。実際のテーブルへの追加の検索。
