説明します
機能
クエリを見つけ、その後のSHOW STATUS、SHOWプロファイルを使用するようにスロークエリの実行に比較的長い時間を使用して私たちの毎日の使用では、分析を行うと、単一の文を説明します。
使用すると、彼らはあなたのMySQLのSQL文に対処する方法を知っているので、SQLクエリオプティマイザが実行を説明シミュレートするためのキーワード。あなたのクエリまたはテーブル構造におけるパフォーマンスのボトルネックの分析。
具体的な分析され
- 読み上げ順序テーブル
- データは操作の操作タイプを読み取ります
- どのインデックスを使用することができます
- どのインデックスが実際に使用されています
- テーブル間の参照
- どのように多くの行のクエリオプティマイザの各テーブル
構文を使用し
たSQL文を説明
何の結果となっている
が10、それぞれ、ID、SELECT_TYPE、テーブル、種類、外の情報をexpain possible_keys、キー、key_lenに、REF、行、エクストラ
概要フィールド説明しました：
- ID：識別子を選択
- SELECT_TYPEは：クエリのタイプを示します。
- 表：表出力セット
- パーティション：パーティションの試合
- タイプ：接続テーブルの種類を表し
- possible_keys：クエリを表す場合は、インデックスが使用される可能性があります
- キー：実際の使用のインデックスを示し
- インデックスフィールドの長さ：key_lenに
- REF：列のインデックスとの比較
- 走査線の数（行の推定数）：行
- 濾過：表の行フィルタリング条件の百分率
- エクストラ：説明と手順の実施
フィールドを詳細に説明しました
A、IDの
配列同一SQLクエリの実行
1. ID、上から下への順番と同じです
2. IDクエリが子供である場合に、同時に、IDシリアル番号がインクリメントされていない、id値より大きい高い優先度、実行される最初
3.同じと異なるIDが存在は、同じIDと、実行ダウンの順序から、グループとして考えることができる、全ての群において、より大きなID値、優先順位の高い、最初の実行
二つ、SELECT_TYPEは
サブクエリ複雑なクエリとして、参加、主に通常のクエリを区別するために使用される各タイプの句は、SELECTクエリ
（1）SIMPLE（UNIONまたはサブクエリを使用しない単純なSELECT、など）
（2）一次（副最も外側の選択は、プライマリとしてマークされているクエリ最も外側のクエリ、クエリが複雑なサブ部分を含む場合、）
（3）UNION（2番目以降UNION SELECT文）
（4）DEPENDENT UNION（ UNIONの二回目以降の文をSELECTクエリの外に依存する）
（5）結果UNION（UNIONの結果、第二以降の選択組合を開始するすべての文を選択）
（6）サブクエリ（最初のサブクエリSELECT、その結果を外部クエリに依存しない）
（7）依存サブクエリ（最初のサブクエリSELECT、外部クエリに依存している）
（8）は、句サブクエリから（派生テーブルSELECT由来）
（9 ）結果UNCACHEABLEサブクエリ（サブクエリをキャッシュすることはできません、あなたは再評価の最初の行がリンクされている必要があります）
三、テーブルの
このステップは、アクセス表示、データベーステーブル名（このラインの表示データがテーブルが何であるかです）
四、タイプ
また、「アクセスタイプ」として知られている、テーブル内の所望の線を表現する方法を見つけるのMySQL次のように、一般的なタイプは次のとおりです。
ALL、インデックス、範囲、REF、でeq_ref、constの、システム、NULL
左から右へ、最悪から最高のパフォーマンスに
一般的に言って。クエリは、少なくとも範囲レベル最善を参照達成することを保証しなければなりません。
すべてのアクセスタイプをソート：
システムテーブルは通常発生しない、特殊なタイプのconstである（システムテーブルに等しい）だけの行を有し、これは無視できます。
CONST：データが一致の唯一の行は、すぐためインデックスは、一意の主キーまたはインデックスを比較するために一度見出さ、CONSTで表される
一次キー・リストは、MySQLの順序が一定にクエリを変換する場合のように配置されます
でeq_ref：ユニークなインデックススキャンでは、各インデックスキーのために、唯一のテーブルには、1つのレコードのみを一致させます。主キーまたは一意索引スキャンで共通
REF：非ユニークインデックス・スキャン、リターンは、すべての行の単一の値と一致するように、本質的には、インデックスアクセスの一種である、それは単一の値の一致する行を返し、しかし、あなたはそれがより多くの行を修飾するかもしれません、インデックス彼は、検索とスキャンの混合物に属している必要があります
範囲：行のみを選択するためにインデックスを使用して、与えられた範囲の行を検索します。
一般的にインデックスを使用するキー列のショーは、あなたの声明で存在する間、<、>、他のクエリでは
、それが唯一の指標の中でいくつかの点で開始する必要があるため、スキャン、インデックススキャンがより良いフルテーブルスキャンよりも及びます、端面別のポイントは、インデックス全体をスキャンしません。
インデックス：フルインデックススキャン、インデックスとすべての違いだけで、インデックスファイルはデータファイルよりも通常小さいため、通常より速くALLよりもインデックス・ツリー・インデックス・タイプを、横断され、
そのインデックスはALLで、リスト全体を読みますが、インデックスは、インデックスから読み出し、ALLは、ディスクから読み込まれているが。
ALL：全表スキャン、MySQLは一致する行を見つけるために、テーブル全体を横断します。NULL：行う場合、最適化プロセスでのMySQL分解文も、テーブルまたはインデックスへのアクセスなしでは、例えば、最小値で索引付けされた列から選択は、個別のインデックス・ルックアップを介して行うことができます。
五は、possible_keysは、
一つ以上の、インデックスがこの表で使用することができる表示します。
フィールドに関連するクエリのインデックスがある場合、インデックスが記載されているが、必ずしもそうではない実際のクエリされます。
簡単に言えば、MySQLはこのインデックスのクエリを使用することができるものをと思います。
六、キー
MySQLのキー列が示すキー（インデックス）を使用する実際の決定は、possible_keysに含まれている必要があります
あなたは、インデックスを選択しない場合、キーはNULLです。使用にMySQLを強制したりpossible_keys列のインデックス、クエリで使用するFORCE INDEX、USE INDEXを無視するか、INDEXを無視します。
七、key_lenに
、インデックスがクエリに使用することができるインデックスに使用されるバイトの数は、インデックスフィールドの最大可能長さの値は、key_lenに表示される列の長さ（はなく、実際の長さ、すなわち、によって算出されていることを示し、基準key_lenにテーブル定義にない計算されますテーブルによって取得）
同じクエリが、精度を損なうことなく、夏にはできるだけ短いとして長さをもたらします 。
八、REF
可能な場合、使用される表示列インデックスは、列またはクエリインデックス列の値のために使用される一定の定数、です。
九、行
結果セットの行数を推定し、MySQLのテーブルの統計情報とインデックスの選択を示すためによると、行の推定数を読み出すべきレコードを検索するために必要な
テン、エクストラ
このフィールドには、次のような状況の解決の詳細にMySQLのクエリが含まれています。
filesortレコードを使用します：
MySQLは代わりに、テーブルのインデックス順の読み出し、外部データの順序インデックスを用いて説明します。
現在、このクエリを最適化する場合、MySQLは、「ソート・ファイル」と呼ばれる指標の並べ替え操作を使用して行うことはできません。
簡単に言えば：MySQLのないあなたが見つけるために作成したインデックスに基づいて、
一時的な使用：
クエリ結果をソートするために一時テーブルを使用することで、MySQLを中間結果を保持するために一時テーブルを使用してください。でクエリグループをソートし、グループ化することで順番に共通します。
インデックスを使用します：
表示動作テーブルのデータ列、良好な効率をアクセス避けるために、選択したインデックス被覆（被覆インデックス）に対応します。
どこを同時に使用している場合は、番組インデックスは、検索インデックスキーの値を実行するために使用されていること。
それはインデックスがデータを読み取るのではなく、ルックアップ操作を実行するために使用されていることではない翼同時に、ショーをしなければ。
どこ使い方：
どこのフィルタを使用すること
バッファへの参加の使用：
接続キャッシュを使用します
不可能な場所：
節が常に偽である場合、任意のタプルを取得するために使用することはできません
