MySQL Explain詳細(転載)
5811 ワード
テキストアドレス
日常の仕事の中で、私达は时々遅いクエリーを开いていくつかの実行时间の比较的に长いSQL文を记录して、これらのSQL文を探し出して终わったことを意味しないで、时には私达はよくexplainのこのコマンドを使って1つのこれらのSQL文の実行计画を见て、このSQL文がインデックスを使ったかどうかを见て、全表のスキャンをしましたかこれはexplainコマンドで表示できます.したがって、MySQLのオーバーヘッド・ベースのオプティマイザについて詳しく説明すると、オプティマイザが考慮する可能性のあるアクセス・ポリシーの詳細や、SQL文を実行するときにオプティマイザが採用すると予想されるポリシーの詳細も多く入手できます.(QEP:sql実行計画query Execution planを生成)
各列の意味は次のとおりです. id:SELECTクエリの識別子.SELECTごとに一意の識別子が自動的に割り当てられます. select_type:SELECT検索のタイプ. table:クエリーされたテーブル partitions:一致するパーティション type:joinタイプ possible_keys:今回のクエリで選択可能なインデックス key:今回のクエリで正確に使用するインデックス. ref:keyとともに使用されるフィールドまたは定数は です. rows:このクエリが合計何行スキャンされたかを表示します.これは推定値です. filtered:このクエリ条件でフィルタされたデータの割合を示す . extra:追加情報 一、id
私の理解はSQLが実行する順序の標識で、SQLは大きいから小さいまで実行します id相同時に、実行順序は上から下まで である.サブクエリの場合、idのシーケンス番号は増加し、id値が大きいほど優先度が高くなり、 が先に実行される. idが同じであれば、上から順に実行されるグループとみなすことができる.すべてのグループにおいて、id値が大きいほど優先度が高くなり、 が先に実行する.
二、select_type
クエリー内の各select句のタイプ SIMPLE(単純SELECT、UNIONやサブクエリなどを使用しない) PRIMARY(クエリに複雑なサブ部分が含まれている場合、最外層のselectはPRIMARYとしてマークされる) . UNION(UNIONの2番目または後のSELECT文) DEPENDENT UNION(UNIONの2番目またはそれ以降のSELECT文、外部のクエリに依存) ユニオンRESULT(ユニオンの結果) SUBQUERY(サブクエリの最初のSELECT) DEPENDENT SUBQUERY(サブクエリの最初のSELECT、外部クエリに依存) DERIVED(派生テーブルのSELECT,FROM句のサブクエリ) UNCACHEABLE SUBQUERY(サブクエリの結果はキャッシュできません.外部リンクの最初の行を再評価する必要があります) 三、table
この行を表示するデータはどのテーブルに関するもので、実際のテーブルの名前ではない場合があります.derivedxが表示されます(xは数字で、私の理解はいくつかのステップで実行された結果です).
四、type
MySQLがテーブルに必要なローを見つける方法を表し、「アクセス・タイプ」とも呼ばれます.
よく使われるタイプは、ALL、index、range、ref、eq_です.ref,const,system,NULL(左から右へ、性能が悪いから良い) ALL:Full Table Scan、MySQLは、一致するローを見つけるためにテーブル全体を巡回します. index:Full Index Scan,indexとALLはindexタイプがインデックスツリーのみを巡ると区別される. range:指定された範囲のローのみを取得し、インデックスを使用してローを選択します. ref:インデックス列の値を検索するために使用されるカラムまたは定数を表す上記のテーブルの接続一致条件. eq_ref:refのように、違いは使用するインデックスが一意のインデックスであり、インデックスキー値ごとにテーブルにレコードマッチングが1つしかない.簡単に言えば、マルチテーブル接続でprimary keyまたはunique keyを関連条件として使用する. const、system:MySQLがクエリの一部を最適化し、定数に変換するときに使用します.プライマリ・キーをwhereリストに配置すると、MySQLはクエリを定数に変換できます.systemはconstタイプの特例で、クエリのテーブルが1行しかない場合はsystemを使用します. NULL:MySQLは最適化中に文を分解し、実行時にテーブルやインデックスにアクセスする必要もありません.たとえば、インデックス列から最小値を選択すると、個別のインデックスで検索できます.
五、possible_keys
MySQLがどのインデックスを使用してテーブルにレコードを見つけることができるかを示します.クエリーに関連するフィールドにインデックスが存在する場合、そのインデックスはリストされますが、クエリーで使用されるとは限りません.列は、EXPLAIN出力で示されるテーブルの順序とは完全に独立している.これはpossible_keysのいくつかのキーは実際に生成されたテーブルの順序で使用できません. カラムがNULLの場合、関連するインデックスはありません.この場合、WHERE句が特定の列またはインデックスに適した列を参照しているかどうかを確認することで、クエリーのパフォーマンスを向上させることができます.もしそうであれば、適切なインデックスを作成し、EXPLAINでクエリ を再度チェックする.
六、Key
key列MySQLが実際に使用を決定したキー(インデックス)を表示
インデックスが選択されていない場合は、キーはNULLです.MySQLにpossibleの使用を強制または無視するにはkeys列のインデックスは、クエリーでFORCE INDEX、USE INDEX、またはIGNORE INDEXを使用します.
七、key_len
精度を損なわない場合は、長さが短いほど良い
インデックスで使用されるバイト数を表し、クエリで使用されるインデックスの長さを計算します(key_lenに表示される値はインデックスフィールドの最大可能な長さであり、実際の使用長ではありません.つまり、key_lenはテーブル定義に基づいて計算され、テーブル内で取得されるものではありません).
八、ref
インデックス・カラムの値を検索するために使用されるカラムまたは定数を表す接続一致条件
九、rows
MySQLは、テーブル統計およびインデックスの選択状況に基づいて、必要なレコードを見つけるために読み込むローの数を推定します.
十、Extra
この列には、MySQLのクエリー解決の詳細が含まれています.次のような場合があります. Using where:カラムデータは、インデックス内の情報のみを使用して実際の行動を読み取らなかったテーブルから返されます.これは、テーブルのすべての要求列が同じインデックスの部分である場合に発生し、mysqlサーバがストレージエンジンでローを検索してからローフィルタリングすることを示します. Using temporary:MySQLは結果セットを格納するためにテンポラリ・テーブルを使用する必要があることを示し、ソートおよびパケット・クエリーによく見られる. Using filesort:MySQLでインデックスを使用できないソート操作を「ファイルソート」と呼びます. Using join buffer:値を変更すると、接続条件を取得する際にインデックスが使用されず、中間結果を格納するためにバッファに接続する必要があることが強調されます.この値が表示された場合、クエリの状況に応じてインデックスを追加してエネルギーを改善する必要がある場合があります. Impossible where:この値はwhere文が条件に合致しない行を強調します. Selecttables optimized away:この値は、インデックスのみを使用することによって、オプティマイザが集約関数の結果から1行だけ戻ることを意味します.
まとめ: EXPLAINは、トリガ、ストレージ・プロシージャに関する情報、またはユーザー定義関数がクエリーに与える影響については教えてくれません. EXPLAINは各種Cacheを考慮しない. EXPLAINは、MySQLがクエリーを実行するときに行った最適化作業を表示できません. の一部の統計情報は推定され、正確な値ではない. EXPALINはSELECT操作しか説明できません.その他の操作はSELECTに書き換えて実行計画を確認します.
日常の仕事の中で、私达は时々遅いクエリーを开いていくつかの実行时间の比较的に长いSQL文を记录して、これらのSQL文を探し出して终わったことを意味しないで、时には私达はよくexplainのこのコマンドを使って1つのこれらのSQL文の実行计画を见て、このSQL文がインデックスを使ったかどうかを见て、全表のスキャンをしましたかこれはexplainコマンドで表示できます.したがって、MySQLのオーバーヘッド・ベースのオプティマイザについて詳しく説明すると、オプティマイザが考慮する可能性のあるアクセス・ポリシーの詳細や、SQL文を実行するときにオプティマイザが採用すると予想されるポリシーの詳細も多く入手できます.(QEP:sql実行計画query Execution planを生成)
mysql> explain select * from servers;
+----+-------------+---------+-----------+------+---------------+------+---------+------+------+---------+-------+
| id | select_type | table | partitions| type | possible_keys | key | key_len | ref | rows | filtered| Extra |
+----+-------------+---------+-----------+------+---------------+------+---------+------+------+---------+-------+
| 1 | SIMPLE | servers | NULL | ALL | NULL | NULL | NULL | NULL | 1 | 100 | NULL |
+----+-------------+---------+-----------+------+---------------+------+---------+------+------+---------+-------+
1 row in set (0.03 sec)
各列の意味は次のとおりです.
私の理解はSQLが実行する順序の標識で、SQLは大きいから小さいまで実行します
二、select_type
クエリー内の各select句のタイプ
この行を表示するデータはどのテーブルに関するもので、実際のテーブルの名前ではない場合があります.derivedxが表示されます(xは数字で、私の理解はいくつかのステップで実行された結果です).
mysql> explain select * from (select * from ( select * from t1 where id=2602) a) b;
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
| 1 | PRIMARY | | system | NULL | NULL | NULL | NULL | 1 | |
| 2 | DERIVED | | system | NULL | NULL | NULL | NULL | 1 | |
| 3 | DERIVED | t1 | const | PRIMARY,idx_t1_id | PRIMARY | 4 | | 1 | |
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
四、type
MySQLがテーブルに必要なローを見つける方法を表し、「アクセス・タイプ」とも呼ばれます.
よく使われるタイプは、ALL、index、range、ref、eq_です.ref,const,system,NULL(左から右へ、性能が悪いから良い)
五、possible_keys
MySQLがどのインデックスを使用してテーブルにレコードを見つけることができるかを示します.クエリーに関連するフィールドにインデックスが存在する場合、そのインデックスはリストされますが、クエリーで使用されるとは限りません.
六、Key
key列MySQLが実際に使用を決定したキー(インデックス)を表示
インデックスが選択されていない場合は、キーはNULLです.MySQLにpossibleの使用を強制または無視するにはkeys列のインデックスは、クエリーでFORCE INDEX、USE INDEX、またはIGNORE INDEXを使用します.
七、key_len
精度を損なわない場合は、長さが短いほど良い
インデックスで使用されるバイト数を表し、クエリで使用されるインデックスの長さを計算します(key_lenに表示される値はインデックスフィールドの最大可能な長さであり、実際の使用長ではありません.つまり、key_lenはテーブル定義に基づいて計算され、テーブル内で取得されるものではありません).
八、ref
インデックス・カラムの値を検索するために使用されるカラムまたは定数を表す接続一致条件
九、rows
MySQLは、テーブル統計およびインデックスの選択状況に基づいて、必要なレコードを見つけるために読み込むローの数を推定します.
十、Extra
この列には、MySQLのクエリー解決の詳細が含まれています.次のような場合があります.
まとめ: