MySQLのパフォーマンスのアーティファクトは説明します

この記事は関連：アーティファクトの使用のMySQLのパフォーマンスの最適化を説明します

簡単な紹介

すぐにチューニングする私たちのSQLを説明使用することはできませんが、それは私たちにいくつかの調整案を与えることはできませんが、それは私たちがSQL文を実行しているかのMySQLを最適化するために理解することができます

説明することで、我々は次の結果を分析することができます。

読み上げ順序テーブル
データは操作の操作タイプを読み取ります
どのインデックスを使用することができます
どのインデックスが実際に使用されています
テーブル間の参照
どのように多くの行のクエリオプティマイザの各テーブル

コマンドの使用方法は非常に簡単で説明し、プラスselect文は、例えば前に説明してください。

1	説明選択 * からユーザー。

これは、主に以下のフィールドが含ま結果
ID、SELECT_TYPE、テーブル、パーティション、余分な、フィルタタイプ、possible_keys、キー、REF、行を、
私たちは各フィールドの意味を見て次

IDクエリのシリアル番号

ローディング順序テーブル

と同じであるので、両方の1テーブルのクエリロード順序を結合

サブクエリを含む場合、サブクエリを実行するので、最大ユーザID値テーブル

SELECT_TYPEクエリの種類

一般的な値は次のとおりです。

SIMPLE：単純にクエリを選択し、クエリがサブインデックスが含まれていません
PRIMARY：クエリは任意のサブクエリが含まれている場合は、最も外側のクエリは、PRIMARYとして記録しました
SUBQUERY：SELECTリスト内のサブクエリが含まれていますか
派生：リストに含まれるサブクエリが（誘導体）由来マークされ、MySQLは一時テーブルで再帰的にこれらのサブクエリ、結果れよう
UNION：第SELECTインデックスに表示された後に、UNIONを標識した場合は、次のインデックスは、クエリのFROM句、外層はSELECT標識されているに含まれている場合：派生
UNION結果：インデックステーブル、クエリから結果を取得します

テーブルルックアップテーブルまたは関連する派生テーブル

タイプのクエリの種類

タイプフィールドによって、私たちは問い合わせが全表スキャンまたはインデックス・スキャンであるかを決定することができ、種類一般的に使用される値は次のとおりです。

システム：一つだけのデータテーブル
CONST：同等のクエリのためには、例えば、次のクエリの主キーインデックス、あなたがデータを読み取るために得れば理解することは簡単で、主キーまたは一意のインデックスをスキャン
でeq_ref：ユニークインデックススキャン、各インデックス・キー、テーブルの試合で1つのレコードのみのため。主キーまたは一意索引スキャンで共通
参考文献：非一意のインデックススキャンは、別の値に一致するすべての行を返します
範囲：クエリ表示指標の範囲、例えば、=、<>、>、> =、<、<=、IS、NULL、<=>、BETWEEN、IN、等
インデックス：インデックス・ツリーに直接照会するデータは、次のような、データをスキャンする必要がなく、取得することができます
ALL：全表スキャンを表し、これはクエリのパフォーマンスクエリの最悪のタイプです

タイプTYPEのパフォーマンスの比較
次のように一般的に、パフォーマンスのタイプ関係の異なる種類を話すには、次のとおりです。
ALL <指数<レンジ<REF <でeq_ref <constの<システム

インデックスは、ときpossible_keysを照会するために使用することができます。

MySQLのクエリで表さpossible_keysインデックスを使用することができる。必ずしも使用しないように注意し、実際の使用は、キーフィールドによって決定されます

クエリで使用されるキーインデックス

このフィールドは、実際にインデックスを使用するには、現在のMySQLのクエリです。

key_lenにバイトのインデックス番号を使用して

このフィールドは、複合インデックスが完全に使用されて評価することができる、またはフィールドのみ左端部分がために使用されます。

データをスキャンする必要があるのセットMySQLの結果が行を読むための行数の推定値を見つけるには

余分な追加情報

いくつかの共通要素があります。

filesortレコードを使用する：このような問合せ大きなCPUリソースの消費ので、MySQLの追加のソート操作は、一般的にfilesortレコードを使用した場合の効果を達成するために、インデックス順にソートすることができない、削除の最適化を示唆しています。
インデックスを使用する：多くの場合、良好なパフォーマンスを示して、クエリはテーブルデータファイルをスキャンせずにインデックスツリー内のデータを見つけることができることを示しています
一時的な使用：一時テーブルを使用するクエリはありますが、通常、グループ化、並べ替えの場合に表示され、マルチテーブル結合、クエリの効率は、提案された最適化の高いものではありません。
どこ使い方：そのフィルタ場所の使用
バッファに参加使用：接続キャッシュの使用は、例えば、クエリ時に、非常に大規模なマルチテーブルの数が参加することを、バッファ設定ファイルは、バッファ転送多数の参加します
どこ不可能：節が常に偽である場合には、任意のタプルを取得するために使用することはできません
離れて最適化されたテーブルを選択：インデックスの最適化MIN / MAX操作やMyISAMストレージエンジンの最適化COUNT（*）の操作に基づいて、どのような状況GROUPBY句の下では、実装フェーズを待って、その後に計算せずに、生成されたクエリ実行プランの最適化フェーズが完了しています
別個：別個の操作の最適化は、最初に一致するタプルは同一の値を見つけるために動作を停止した後に発見されます