実行計画パラメータを詳細に説明する
mysql> explain select * from kt_course order by create_time desc;
+----+-------------+-----------+------+---------------+------+---------+------+------+----------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------+------+---------------+------+---------+------+------+----------------+
| 1 | SIMPLE | kt_course | ALL | NULL | NULL | NULL | NULL | 29 | Using filesort |
+----+-------------+-----------+------+---------------+------+---------+------+------+----------------+
1 row in setselect_type
1）単純：単純なSELECT。実用的なUNIONやサブクエリではありません。
2）PRIMARY：最も外側のSELECT。
3）UNION：2番目のレイヤーはSELECTの後にUNIONを使用します。
4）DEPENDENT UNION：UNIONステートメントの2番目のSELECTは、外部サブクエリに依存します。
5）UNION RESULT：UNIONの結果。
6）サブクエリ：サブクエリの最初のSELECT。
7）従属サブクエリ：サブクエリの最初のSELECTは、外部のクエリに依存します。
8）派生：エクスポートされたテーブルのSELECT（FROM句のサブクエリ）
テーブル
この行のデータに関するテーブルを表示します
タイプ
typeフィールドはより重要であり、クエリが効率的かどうか、使用されている全表扫描か索引扫描待機しているかを識別します
これは、使用されている接続のタイプを示す重要な列です。
最高から最低までの接続タイプ：const、eq_reg、ref、範囲、インデックス、およびALL
タイプ：主に以下の集中型を含む、テーブルに使用されるアクセス方法を教えてください。
1）all：全表スキャン。
2）const：定数を読み取ります。これは定数であるため、多くても1つのレコードのみが一致します。実際には一度だけ読み取る必要があります。
3）eq_ref：通常、主キーまたは一意のキーインデックスを介してアクセスされる一致結果は最大1つです。
4）全文検索：全文索引検索。
5）インデックス：フルインデックススキャン。
6）index_merge：クエリで2つ（またはそれ以上）のインデックスを同時に使用し、インデックスの結果をマージ（マージ）してから、テーブルデータを読み取ります。
7）index_subquery：サブクエリで返される結果フィールドの組み合わせはインデックス（またはインデックスの組み合わせ）ですが、主キーや一意のインデックスではありません。
8）鳴った：インデックス範囲スキャン。
9）ref：結合ステートメントのドリブンテーブルのインデックスによって参照されるクエリ。
10）ref_or_null：refとの唯一の違いは、インデックスによって参照されるクエリに加えて空の値を追加するクエリです。
11）システム：システムテーブル、テーブル内のデータ行は1行のみです
。12）unique_subquery：サブクエリで返された結果フィールドの組み合わせは、主キーまたは一意制約です。
possible_keys
このテーブルに適用される可能性のあるインデックスを表示します。空の場合、可能なインデックスはありません。関連するドメインのWHEREステートメントから適切なステートメントを選択できます
キー
使用される実際のインデックス。NULLの場合、インデックスは使用されません。まれに、MYSQLが最適化されていないインデックスを選択することがあります。この場合、SELECTステートメントでUSE INDEX（インデックス名）を使用してインデックスを強制するか、IGNORE INDEX（インデックス名）を使用してMYSQLにインデックスを無視させることができます
key_len
使用されるインデックスの長さ。精度を失うことなく、長さが短いほど良い
key_lenの計算方法 https://www.cnblogs.com/gomysql/p/4004244.html
ref
インデックスのどの列が使用されたか、可能であれば定数を表示します
行
mysqlクエリオプティマイザは、統計情報に基づいて結果セットを見つけるためにSQLでスキャンして読み取る必要のあるデータ行の数を推定します。この値は、SQLの効率を直感的に反映できます。原則として、行の値が小さいほど優れています
追加
MYSQLがクエリを解析する方法に関する追加情報。表4.3で説明しますが、ここで確認できる悪い例は、一時的な使用とファイルソートの使用です。つまり、MYSQLはインデックスをまったく使用できず、結果として取得が遅くなります。
追加フィールドの説明
Extra：クエリの各ステップに関する追加の詳細情報、主に以下。
区別：個別の値を検索するmysqlが最初に一致する結果を見つけると、この値のクエリを停止し、後で他の値に切り替えます。
NULLキーのフルスキャン：主にインデックスでアクセスできないnull値を使用するサブクエリの最適化方法。
各レコードのチェック範囲（インデックスマップ：N）：MySQL公式マニュアルの説明によると、MySQLクエリオプティマイザーが使用できる適切なインデックスを見つけられない場合、前のテーブルの列の値がわかっていれば、いくつかのインデックスを使用できます。上記の表の各行の組み合わせについて、MySQLはrangeまたはindex_mergeアクセスメソッドを使用して行をリクエストできるかどうかを確認します。
最適化されたSELECTテーブル：特定の集計関数を使用してインデックスを持つフィールドにアクセスすると、MySQL Query Optimizerは必要なデータ行をインデックスを通じて直接検索し、クエリ全体を完了します。もちろん、前提となるのは、QueryでGROUP BY操作を実行できないことです。MIN（）またはMAX（）を使用する場合。
filesortの使用：ORDER BYオペレーションがクエリに含まれていて、インデックスを使用してソートオペレーションを完了できない場合、MySQLクエリオプティマイザーは対応するソートアルゴリズムを選択して実行する必要があります。
インデックスの使用：必要なデータはインデックスでのみ取得でき、データを取得するためにテーブルに移動する必要はありません。
group-byのインデックスの使用：データアクセスはインデックスの使用と同じです。必要なデータはインデックスを読み取るだけでよく、クエリでGROUP BYまたはDISTINCT句を使用する場合、グループ化フィールドもインデックスにある場合、Extraの情報は次のようになります。 group-byにインデックスを使用します。
一時の使用：MySQLが特定の操作で一時テーブルを使用する必要がある場合、一時の使用が追加情報に表示されます。GROUP BYやORDER BYなどの操作で主に使用されます。
場所の使用：テーブルのすべてのデータを読み取らない場合、またはインデックスを作成するだけで必要なすべてのデータを取得できる場合は、場所の情報が表示されます。
プッシュされた条件でwhereを使用する：これはNDBClusterストレージエンジンでのみ表示されるメッセージであり、使用する前に条件プッシュダウン最適化機能を有効にすることによってもオンにする必要があります。制御パラメーターはengine_condition_pushdownです。
constテーブルを読んだ後、不可能に気づいたWHERE：MySQL Query Optimizerは、収集された統計情報から結果がない可能性があると判断します。
テーブルなし：クエリステートメントでFROM DUALを使用するか、FROM句を含めないでください。
存在しない：一部の左結合では、MySQLクエリオプティマイザーが元のクエリの構成を変更することによって使用されるメソッドを最適化し、データアクセスの数を部分的に減らすことができます。
結合の最適化
要件：org_knowledge_department_active_weekテーブル（1664万）とorg_knowledge_department_study_monthテーブル（280万）の同じorgidデータの統計。
org_knowledge_department_active_week構造情報
org_knowledge_department_study_month構造情報
EXPLAIN
SELECT
*
FROM
org_knowledge_department_active_week t1
STRAIGHT_JOIN org_knowledge_department_study_month t2
ON t1.orgid = t2.orgid
このSQLステートメントの実行プロセス：
- テーブルt1からデータRの行を読み取る
- データRからフィールドorgidを取得し、テーブルt2で検索します。
- テーブルt2の条件を満たすデータを取り出し、結果セットの一部としてRを含む行を形成します。
- t1テーブルの終わりまで、手順1〜3を繰り返します。
このアルゴリズムは、インデックスのネストされたループ結合（NLJ）：ネストされた検索であり、駆動されたテーブルのインデックスを使用します。
t1テーブル
t2テーブル
結合アルゴリズム：
インデックスネストループ結合（NLJ）：
ネストされたループ結合（INL）のブロック：
おわりに
