説明コマンドのキーメトリックには、タイプ、キー、行、および追加が含まれます。 1）タイプは、クエリのアクセスタイプを反映しています。値が高いほど、constなどの効率が高くなります。 2）キーは使用されているインデックスを表示し、nullはインデックスがないことを示します。 3）行はスキャンされた行の數(shù)を推定し、クエリのパフォーマンスに影響します。 4）追加情報(bào)を最適化する必要があるFilesortプロンプトを使用するなど、追加情報(bào)を追加します。

導(dǎo)入

データベースの最適化について話すとき、 EXPLAINコマンドは私たちの手の強(qiáng)力なツールであり、SQLクエリの実行計(jì)畫を覗き込むのに役立ちます。今日は、説明出力、 type 、 key 、 rows 、およびExtra EXPLAIN説明の重要なインジケーターを詳細(xì)に調(diào)べます。これらのメトリックは、クエリがどのように実行されるかを明らかにするだけでなく、データベースを最適化するための貴重な手がかりを提供します。この記事を読むと、これらのメトリックを解釈し、それらを使用してデータベースのパフォーマンスを向上させる方法を?qū)Wびます。

基本的な知識(shí)のレビュー

EXPLAINコマンドは、SQLステートメントの実行計(jì)畫を表示するためにMySQLで使用されます。クエリの実行方法、インデックスの使用方法、推定行數(shù)などの情報(bào)を理解するのに役立ちます。この情報(bào)の基本概念を理解することは、その後の詳細(xì)な分析にとって重要です。

• type ：MySQLがテーブルで行を検索する方法を示します。クエリのアクセスタイプ、最適から最悪まで、順番に反映されます： system 、 const 、 eq_ref 、 ref 、 range 、 index 、 ALL 。
• key ：MySQLが使用することを決定したインデックスを表示します。インデックスが使用されない場合、ここにNULLが表示されます。
• rows ：MySQLがスキャンする必要がある行の數(shù)を推定します。この數(shù)は、クエリの効率を評(píng)価するために重要です。
• Extra ：一時(shí)テーブルの使用、ファイルの並べ替えなど、他の列の表示には適していない追加情報(bào)が含まれています。

コアコンセプトまたは関數(shù)分析

typeの定義と関數(shù)

typeフィールドは、 EXPLAIN出力で最も直感的なメトリックの1つであり、MySQLがテーブル內(nèi)の行にどのようにアクセスするかを示します。 typeの値が高いほど、クエリ効率が高くなります。たとえば、 const 1つの行のみにアクセスできることを意味しますが、 ALL平均フルテーブルスキャンは、最も効率的なアクセスタイプではありません。

簡単な例を見てみましょう：

 id = 1からselect * fromユーザーから説明します。

idが主キーであり、MySQLがこの行を直接見つけることができるため、出力はtypeがconstあることを示す場合があります。

keyの定義と機(jī)能

keyフィールドには、MySQLがクエリの実行時(shí)に使用することを選択したインデックスが表示されます。適切なインデックスがない場合、MySQLは完全なテーブルスキャンを選択し、 key NULLとして表示されます。適切なインデックスを選択することは、クエリパフォーマンスを改善するために重要です。

例えば：

 select * fromユーザー= 'john'を説明します。

nameフィールドにインデックスがある場合、 keyインデックスの名前を表示する場合があります。

rowsの定義と関數(shù)

rowsフィールドは、MySQLがスキャンすると推定する行の數(shù)を表します。この數(shù)は、より多くの行がスキャンされるほど、クエリが時(shí)間がかかるため、クエリのパフォーマンスに直接影響します。

例えば：

 30歳以上のユーザーからselect *を説明します。

ageフィールドにインデックスがない場合、 rows多數(shù)の數(shù)字を表示し、多數(shù)の行をスキャンする必要があることを示す場合があります。

Extraの定義と機(jī)能

Extraフィールドには、クエリの実行方法を理解するために非常に役立つ可能性のある追加情報(bào)が含まれています。たとえば、 Using temporaryまたはUsing filesortている場合、またはこれは通常、クエリを最適化する必要があることを意味します。

例えば：

 select * fromユーザーは名前で注文します。

nameフィールドがインデックス化されていない場合、 Extra Using filesort表示される場合があります。これは、MySQLがファイルソートを必要とすることを示し、パフォーマンスに影響します。

使用の例

基本的な使用法

簡単なクエリとそのEXPLAIN出力を見てみましょう。

 id = 1からselect * fromユーザーから説明します。

出力は次のとおりです。

 ---- ------------- ------- ------- --------------- --------- --------- ------- ------ ------- 
| ID | select_type |表|タイプ|可能性のある|キー| key_len | ref |行|余分な|
 ---- ------------- ------- ------- --------------- --------- --------- ------- ------ ------- 
| 1 |単純|ユーザー| const |プライマリ|プライマリ| 4 | const | 1 | |
 ---- ------------- ------- ------- --------------- --------- --------- ------- ------ -------

ここでは、 typeがconst 、 key PRIMARYであり、 rows 1であることがわかります。これは、mysqlがプライマリキーインデックスを介してこの行を直接見つけたことを示しています。

高度な使用

それでは、より複雑なクエリを見てみましょう。

 select * from users uにuに參加するselect * oで注文に參加するu.id = o.user_id u.age> 30;

出力は次のとおりです。

 ---- ------------- ------- -------- --------------- --------- --------- --------------- ------ ------------- 
| ID | select_type |表|タイプ|可能性のある|キー| key_len | ref |行|余分な|
 ---- ------------- ------- -------- --------------- --------- --------- --------------- ------ ------------- 
| 1 |単純| u |範(fàn)囲|プライマリ、年齢|年齢| 4 | null | 100 | WHERE |を使用します
| 1 |単純| o | ref | user_id | user_id | 4 | test.u.id | 10 | |
 ---- ------------- ------- -------- --------------- --------- --------- --------------- ------ -------------

ここではtypeがrangeとref 、 key ageとuser_idであり、 rowsそれぞれ100と10であることがわかります。これは、MySQLが最初にage Indexを介して基準(zhǔn)を満たすユーザーを見つけ、次にuser_idインデックスを介して関連する順序を見つけることを示しています。

一般的なエラーとデバッグのヒント

EXPLAINを使用する場合の一般的なエラーは次のとおりです。

• Using filesortやUsing temporaryなど、 Extraフィールドでの警告を無視します。
• 一般的に使用されるクエリには適切なインデックスが作成されていないため、 key NULLになります。
• 実際には推定値である場合、実際にスキャンされた行の數(shù)であると考えて、 rowsフィールドは誤解されています。

これらの問題をデバッグする方法は次のとおりです。

• Extraフィールドを注意深く読み、ソートされたフィールドにインデックスを追加するなど、プロンプトに従って最適化します。
• keyフィールドを分析して、クエリが適切なインデックスを使用していることを確認(rèn)し、そうでない場合はインデックスの追加を検討してください。
• クエリを?qū)g際に実行し、 SHOW PROFILEコマンドを使用して、 rowsフィールドの精度を確認(rèn)します。

パフォーマンスの最適化とベストプラクティス

実際のアプリケーションでは、 EXPLAIN出力の主要な指標(biāo)を最適化すると、データベースのパフォーマンスが大幅に向上する可能性があります。ここにいくつかの最適化の提案があります：

• 一般的に使用されるクエリ條件に適切なインデックスがあることを確認(rèn)し、 rowsの値を減らします。
• 完全なテーブルスキャンを避け、 typeフィールドの値を最適化し、できるだけconst 、 eq_ref 、またはrefを使用してみてください。
• Extraフィールドの警告に注意を払い、ソートされたフィールドにインデックスを追加するなど、プロンプトに従って最適化します。

最適化の前後の比較を見てみましょう。

 - 最適化の前に、「％john％」のような名前からユーザーからselect *を説明します。

 - 最適化されたselect * fromユーザーから「john％」のような名前。

最適化の前に、 type ALLであり、 rowsより大きな數(shù)字である可能性があります。 LIKE '%John%'インデックスを使用できないためです。最適化後、 nameフィールドにインデックスがある場合、 type rangeになり、 rowsの値が大幅に減少します。

プログラミングの習(xí)慣とベストプラクティスに関しては、推奨されます。

• EXPLAINために定期的に使用して分析とクエリを行い、パフォーマンスのボトルネックを迅速に発見して最適化します。
• コードの読みやすさとメンテナンスを維持し、インデックスとクエリロジックが明確で理解しやすいことを確認(rèn)してください。
• 実際のビジネスニーズに基づいて、過度のインデックス作成によって引き起こされるパフォーマンスの劣化を避けるために、合理的に設(shè)計(jì)インデックスを設(shè)計(jì)します。

EXPLAIN出力の重要な指標(biāo)を深く理解して適用することにより、データベースクエリをより効果的に最適化し、アプリケーションの全體的なパフォーマンスを向上させることができます。

以上が説明出力（タイプ、キー、行、追加）で探す重要なメトリックは何ですか？の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。