第09章_パフォーマンス分析ツールの使用

第09章_パフォーマンス分析ツールの使用

1. データベースサーバーの最適化手順

データベースのチューニングの問題が発生した場合、どのように考えるべきでしょうか? ここで思考プロセスを整理すると以下の図になります。

プロセス全体は观察（Show status）2 つの行动（Action）部分に分かれています。文字 S の部分は観察 (対応する分析ツールが使用される) を表し、文字 A の部分はアクション (分析によって実行できるアクションに対応) を表します。

観察を通じてデータベースの全体的な実行状態を理解することができます。パフォーマンス分析ツールを使用すると、どの SQL の実行が遅いのかを把握したり、特定の SQL 実行計画を確認したり、SQL 実行の各ステップのコストを確認したりできるため、問題を特定できます。問題を見つけて、適切なアクションを実行します。

この図を詳しく説明します。

まず、S1 部分では、サーバーのステータスに周期的な変動があるかどうかを観察する必要があります。その場合存在周期性波动、ダブルイレブンやプロモーションなどの周期的なノードが原因である可能性があります。この場合、ステップ A1、つまりキャッシュを追加するか、キャッシュ無効化ポリシーを変更することで解決できます。

キャッシュ戦略が解決されない場合、またはそれが周期的変動の原因ではない場合は、さらに進める必要があります分析查询延迟和卡顿的原因。次に、
S2に入る必要があります开启慢查询。遅いクエリは、実行が遅い SQL ステートメントを見つけるのに役立ちます。パラメーターを設定することで「遅い」のしきい値を定義できlong_query_time、SQL の実行時間が を超えるとlong_query_time遅いクエリとみなされます。これらのスロー クエリを収集した後、分析ツールを使用してスロー クエリのログを分析できます。

S3 ステップでは、実行速度が遅い SQL がわかっているため、EXPLAIN対象を絞った方法で対応する SQL ステートメントの実行計画を表示したり、show profileSQL の各ステップの時間コストを表示したりできます。このようにして、SQL クエリが遅いのは実行時間が長いためなのか、待機時間が長いためなのかを理解できます。

SQL 待ち時間が長い場合は、ステップ A2 に入ります。このステップでは、调优服务器的参数たとえばデータベース バッファ プールを適切に増やすことができます。SQL の実行に時間がかかる場合は、ステップ A3 に進みます。このステップでは、インデックスの設計に問題があるのか​​、クエリに関連付けられているデータ テーブルが多すぎるのか、またはこの現象が原因であるのかを検討する必要があります。データテーブルのフィールド設計の問題。次に、これらの寸法に対応する調整を加えます。

A2 と A3 のどちらでも解決できない場合は、データベース自体の SQL クエリ性能がボトルネックに達していないかを検討し、性能ボトルネックに達していないことが確認できた場合は、再確認して上記の手順を繰り返す必要があります。 。A4 ステージに達している場合は、読み取り/書き込み分離アーキテクチャの採用を検討するか、垂直シャーディング、垂直シャーディング、水平シャーディングなどのデータベース シャーディングを検討する性能瓶颈必要があります。增加服务器分库分表

以上がデータベースチューニングのプロセスの考え方です。SQL の実行時に不規則な遅延やフリーズがあることがわかった場合は、分析ツールを使用して、問題のある SQL を特定できます。これら 3 つの分析ツールは、SQL チューニングの 3 つのステップとして理解できます慢查询、 EXPLAIN。SHOWPROFILING

まとめ：

2. システムパフォーマンスパラメータの表示

MySQL では、ステートメントを使用してSHOW STATUS一部の MySQL データベース サーバーにクエリを実行できます性能参数。执行频率

SHOW STATUS ステートメントの構文は次のとおりです。

SHOW [GLOBAL|SESSION] STATUS LIKE'参数';

一般的に使用されるパフォーマンス パラメーターの一部は次のとおりです。

• 接続: MySQL サーバーに接続する回数。

• 稼働時間: MySQL サーバーのオンライン時間。

• Slow_queries: 遅いクエリの数。

  • デフォルトは10秒以上です

• Innodb_rows_read: 選択クエリによって返される行数

• Innodb_rows_inserted: INSERT 操作の実行によって挿入された行の数

• Innodb_rows_updated: UPDATE 操作によって更新された行の数

• Innodb_rows_deleted: DELETE 操作によって削除された行の数

• Com_select: クエリ操作の数。

• Com_insert: 挿入操作の数。バッチ挿入 INSERT 操作の場合、累積は 1 回だけ実行されます。

• Com_update: 更新操作の数。

• Com_delete: 削除操作の数。

例えば：

# 慢查询次数
show status like 'Slow_queries'; 

スロー クエリ カウント パラメータをスロー クエリ ログと組み合わせて、スロー クエリ ステートメントを見つけて、スロー クエリ ステートメントに対して表结构优化ORを実行することができます查询语句优化。別の例として、次の手順を使用して、関連する手順を表示できます。

show status like 'Innodb_rows_%';

3. SQLクエリコストの統計: last_query_cost

SQL クエリ ステートメントは、クエリを実行する前にクエリ実行プランを決定する必要があります。複数の実行プランがある場合、MySQL は各実行プランのコストを計算し、そのうちの成本最小1 つを最終的な実行プランとして選択します。

特定の SQL ステートメントのクエリ コストを確認したい場合は、SQL ステートメントの実行後に現在のセッション内の変数値をチェックすることで、現在のクエリのコストを取得できます
last_query_cost。それは评价一个查询的执行效率私たちにとっても一般的な指標であることがよくあります。このクエリ コストは に相当しますSQL语句所需要读取的页的数量。

第 8 章でも、例として Student_info テーブルを使用します。

CREATE TABLE `student_info` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`student_id` INT NOT NULL ,
`name` VARCHAR(20) DEFAULT NULL, `course_id` INT NOT NULL ,
`class_id` INT(11) DEFAULT NULL,
`create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

id=900001 のレコードをクエリしてクエリのコストを調べたい場合は、クラスター化インデックスを直接検索できます。

SELECT student_id, class_id, NAME, create_time FROM student_info WHERE id = 900001 ;

走行結果（1件、走行時間0.042s）

次に、クエリ オプティマイザーのコストを見てみましょう。実際、取得する必要があるのは 1 ページだけです。

mysql> SHOW STATUS LIKE 'last_query_cost';
+-----------------+----------+
| Variable_name | Value |
+-----------------+----------+
| Last_query_cost | 1.000000 |
+-----------------+----------+

900001 から 9000100 までの ID を持つ学生レコードをクエリしたい場合はどうすればよいでしょうか?

SELECT student_id, class_id, NAME, create_time FROM student_info
WHERE id BETWEEN 900001 AND 900100;

実行結果（100件、実行時間0.046s）

次に、クエリ オプティマイザーのコストを見てみましょう。この時点では、約 20 ページのクエリを実行する必要があります。

mysql> SHOW STATUS LIKE 'last_query_cost';
+-----------------+-----------+
| Variable_name   |   Value   |
+-----------------+-----------+
| Last_query_cost | 21.134453 |
+-----------------+-----------+

ページ数が以前の 20 倍になっていることがわかりますが、クエリの効率は大きく変わっていません。実際、ページは を使用して一度にロードされるため、2 つの SQL クエリの時間は基本的に同じです。バッファプールに順次読み込んでから、再度検索します。ただし页数量（last_query_cost）增加了不少、バッファ プール メカニズムを通じて、并没有增加多少查询时间.

**使用シナリオ:** これは、特に複数のクエリ方法から選択できる場合に、コストを比較するのに非常に役立ちます。

SQL クエリは動的なプロセスであるため、ページ読み込みの観点からは、次の 2 つの結論を導き出すことができます。

1. 位置决定效率。ページがデータベース内にある場合缓冲池、効率は最も高くなりますが、それ以外の場合磁盘は
   そこから読み取る必要があります。もちろん、単一のページを読み取る場合、ページがメモリ内に存在する場合、メモリから読み取るよりもはるかに効率的になります。ディスク。

2. 批量决定效率。ディスクから単一ページをランダムに読み取る場合、効率は非常に低くなります (ほぼ 10 ミリ秒)。
   シーケンシャル、1 ページの平均読み取り効率は大幅に向上します。メモリ内の単一ページのランダム読み取り。

したがって、/O が発生しても心配する必要はなく、適切な方法を見つければ、効率は依然として非常に高くなります。まず、データの保存場所を考慮する必要があります。頻繁に使用するデータの場合は、中央に配置する必要があります缓冲池。次に、ディスクのスループット容量を最大限に活用して、一度にデータを一括で読み取ることができます。 , これにより、1 ページの読み取り効率も向上します。

4. 実行速度が遅い SQL を特定します: 低速クエリ ログ

MySQL のスロークエリログは、响应时间超过阀值MySQL 内のステートメントを記録するために使用され、具体的には、long_query_time実行時間が値を超えた SQL がスロークエリログに記録されます。long_query_time のデフォルト値は です10。これは、10 秒を超えて実行されるステートメント (10 秒を除く) が最大許容時間値を超えていると見なされることを意味します。|

その主な機能は、特に長い実行時間のかかる SQL クエリを検出し、対象を絞った方法で最適化することで、システム全体の効率を向上させることです。データベース サーバーがブロックされ、動作が遅い場合は、低速クエリ ログをチェックして、低速クエリを見つけると、問題の解決に非常に役立ちます。たとえば、sq| の実行時間が 5 秒を超えた場合、それは遅い SQL であると判断し、5 秒を超えた SQL を収集し、Explain に基づいて包括的な分析を実行したいと考えています。

デフォルトでは、MySQL データベースでは没有开启慢查询日志このパラメータを手動で設定する必要があります。チューニングに必要でない場合は、このパラメータを有効にすることは一般的に推奨されません。これは、スロー クエリ ログを有効にすると、多かれ少なかれパフォーマンスに影響が出るからです。

スロー クエリ ログは、ログ レコードのファイルへの書き込みをサポートしています。

4.1 スロークエリログパラメータを有効にする

1.slow_query_logをオンにする

mysql > show variables like '%slow_query_log%';
mysql > set global slow_query_log='ON';

次に、スロー クエリ ログがオンになっているかどうかと、スロー クエリ ログ ファイルの場所を確認してみましょう。

/var/lib/mysql/atguigu02-slow.logスロークエリ分析が有効になり、ファイルがFileに保存されたことがわかります
。

2.long_query_time しきい値を変更する

次に、次のコマンドを使用して、低速クエリの時間しきい値設定を見てみましょう。

mysql > show variables like '%long_query_time%';

# 测试发现：设置global的方式对当前session的long_query_time失效。对新连接的客户端有效。所以可以一并执行下述语句
mysql> set global long_query_time = 1 ;
mysql> show global variables like ' %long-query_time% ';

# 即更改global 也更改了session变量
mysql> set long_query_time=1;
mysql> show variables like '%long_query_time%';  

補足：設定ファイルにパラメータをまとめて設定する

前述のコマンドライン方法と比較して、次の方法は永続的な設定方法とみなすことができます。

my.cnfファイルを変更し、パラメータを追加または[mysqld]下変更してlong_query_time、MySQL サーバーを再起動します。|slow_query_logslow_query_log_file

[mysqld]
slow_query_log=ON #开启慢查询日志的开关
slow_query_log_file=/var/lib/mysql/my-slow.log #慢查询日志的目录和文件名信息
long_query_time=3 #设置慢查询的阈值为3秒，超出此设定值的SQL即被记录到慢查询日志
log_output=FILE

ストレージ パスを指定しない場合、スロー クエリ ログはデフォルトで MySQL データベースのデータ フォルダーに保存されます。ファイル名を指定しない場合、デフォルトのファイル名は hostname-slow.log です。

4.2 スロークエリの数を確認する

現在のシステムにスロークエリレコードがいくつあるかをクエリします。

SHOW GLOBAL STATUS LIKE '%Slow_queries%';

4.3 ケースデモンストレーション

ステップ 1. テーブルの作成

CREATE TABLE `student` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`stuno` INT NOT NULL ,
`name` VARCHAR(20) DEFAULT NULL,
`age` INT(3) DEFAULT NULL,
`classId` INT(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

ステップ 2: パラメータ log_bin_trust_function_creators を設定する

エラーが報告された場合は関数を作成します。

This function has none of DETERMINISTIC......

コマンドオン: 関数設定の作成を許可します:

set global log_bin_trust_function_creators=1; # 不加global只是当前窗口有效。

ステップ 3: 関数を作成する

文字列をランダムに生成: (前の章と同じ)

DELIMITER //
CREATE FUNCTION rand_string(n INT)
	RETURNS VARCHAR(255) #该函数会返回一个字符串
BEGIN
    DECLARE chars_str VARCHAR(100) DEFAULT
    'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ';
    DECLARE return_str VARCHAR(255) DEFAULT '';
    DECLARE i INT DEFAULT 0;
	WHILE i < n DO
        SET return_str =CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1+RAND()*52),1));
        SET i = i + 1;
	END WHILE;
	RETURN return_str;
END //
DELIMITER ;

ランダムな値を生成する: (前の章と同じ)

#测试
SELECT rand_string(10);

DELIMITER //
CREATE FUNCTION rand_num (from_num INT ,to_num INT) RETURNS INT(11)
BEGIN
DECLARE i INT DEFAULT 0;
SET i = FLOOR(from_num +RAND()*(to_num - from_num+1)) ;
RETURN i;
END //
DELIMITER ;

#测试：
SELECT rand_num(10,100);

ステップ 4: ストアド プロシージャを作成する

DELIMITER //
CREATE PROCEDURE insert_stu1( START INT , max_num INT )
BEGIN
DECLARE i INT DEFAULT 0;
    SET autocommit = 0; #设置手动提交事务
    REPEAT #循环
    SET i = i + 1; #赋值
    INSERT INTO student (stuno, NAME ,age ,classId ) VALUES
    ((START+i),rand_string(6),rand_num(10,100),rand_num(10,1000));
    UNTIL i = max_num
    END REPEAT;
    COMMIT; #提交事务
END //

DELIMITER ;

ステップ 5: ストアド プロシージャを呼び出す

#调用刚刚写好的函数, 4000000条记录,从100001号开始

CALL insert_stu1(100001,4000000);

4.4 テストと分析

1. テスト

mysql> SELECT * FROM student WHERE stuno = 3455655;
+---------+---------+--------+------+---------+
|    id   |  stuno  |  name  |  age | classId |
+---------+---------+--------+------+---------+
| 3523633 | 3455655 | oQmLUr |  19  |    39   |
+---------+---------+--------+------+---------+
1 row in set (2.09 sec)

mysql> SELECT * FROM student WHERE name = 'oQmLUr';
+---------+---------+--------+------+---------+
|    id   |  stuno  |  name  |  age | classId |
+---------+---------+--------+------+---------+
| 1154002 | 1243200 | OQMlUR |  266 |   28    |
| 1405708 | 1437740 | OQMlUR |  245 |   439   |
| 1748070 | 1680092 | OQMlUR |  240 |   414   |
| 2119892 | 2051914 | oQmLUr |  17  |   32    |
| 2893154 | 2825176 | OQMlUR |  245 |   435   |
| 3523633 | 3455655 | oQmLUr |  19  |   39    |
+---------+---------+--------+------+---------+

6 rows in set (2.39 sec)

上記の結果からわかるように、学籍番号「3455655」の学生情報のクエリには2.09秒かかります。学生名「oQmLUr」で学生情報をクエリするのに 2.39 秒かかります。これは秒オーダーに達しており、現在のクエリ効率が比較的低いことがわかりますが、
その理由を次のセクションで分析します。

2.分析

show status like 'slow_queries';

追加情報：

上記の変数に加えて、スロー クエリ ログを制御するシステム変数 min_examined_row_limit もあります。この変数の意味は、 query です扫描过的最少记录数。この変数とクエリ実行時間は、クエリが遅いクエリであるかどうかを判断するための条件を形成します。クエリによってスキャンされたレコードの数がこの変数の値以上で、クエリの実行時間が long_query_time の値を超えている場合、クエリはスロー クエリ ログに記録されます。それ以外の場合、クエリはスロー クエリ ログに記録されません。スロークエリログに記録されます。

mysql> show variables like 'min%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| min_examined_row_limit | 0     |
+------------------------+-------+
1 row in set (0.00 sec)

必要に応じて「my.ini」ファイルを変更することで、「min_examined_row_limit」の値を変更することもできます。

4.5 スロークエリログ分析ツール: mysqldumpslow

運用環境で手動でログを分析したり、SQL を見つけて分析したりするのは明らかに面倒な作業ですが、MySQL にはログ分析ツールが用意されていますmysqldumpslow。

mysqldumpslow のヘルプ情報を表示する

mysqldumpslow --help

mysqldumpslow コマンドの特定のパラメータは次のとおりです。

• -a: 数値を N に抽象化したり、文字列を S に抽象化したりしません。
• -s: 並べ替え方法を示します。
  • c: 訪問数
  • l: ロック時間
  • r: リターンレコード
  • t: クエリ時間
  • al: 平均ロック時間
  • ar: 返されるレコードの平均数
  • at: 平均クエリ時間 (デフォルト モード)
  • ac: 平均クエリ数
• -t: 以前のデータ数を返します。
• -g: 大文字と小文字を区別しない、通常の一致パターンが続きます。

例: クエリ時間で並べ替えて最初の 5 つの SQL ステートメントを表示したいので、次のように記述できます。

mysqldumpslow -s t -t 5 /var/lib/mysql/atguigu01-slow.log

[root@bogon ~]# mysqldumpslow -s t -t 5 /var/lib/mysql/atguigu01-slow.log

Reading mysql slow query log from /var/lib/mysql/atguigu01-slow.log
Count: 1 Time=2.39s (2s) Lock=0.00s (0s) Rows=13.0 (13), root[root]@localhost
	SELECT * FROM student WHERE name = 'S'

Count: 1 Time=2.09s (2s) Lock=0.00s (0s) Rows=2.0 (2), root[root]@localhost
	SELECT * FROM student WHERE stuno = N
	
Died at /usr/bin/mysqldumpslow line 162, <> chunk 2.

仕事に関する一般的な参考資料:

#得到返回记录集最多的10个SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log

#得到访问次数最多的10个SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/atguigu-slow.log

#得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/atguigu-slow.log

#另外建议在使用这些命令时结合 | 和more 使用 ，否则有可能出现爆屏情况
mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log | more

4.6 スロークエリログを閉じる

チューニングのためにオンにする必要がある場合を除き、通常はオンにしないほうがよいでしょう。

MySQL サーバーのスロークエリログ機能を停止するには 2 つの方法があります。

方法 1: 永続的な方法

[mysqld]
slow_query_log=OFF

または、slow_query_log 項目をコメントアウトするか削除します。

mysqld]
#slow_query_log =OFF

MySQL サービスを再起動し、次のステートメントを実行してスロー ログ関数をクエリします。

SHOW VARIABLES LIKE '%slow%'; #查询慢查询日志所在目录
SHOW VARIABLES LIKE '%long_query_time%'; #查询超时时长

方法 2: 一時的な方法

設定するにはSET文を使用します。(1) MySQLのスロークエリログ機能を停止します 具体的なSQL文は以下の通りです。

SET GLOBAL slow_query_log=off;

(2) MySQL サービスを再起動し、SHOW ステートメントを使用してスロー クエリ ログ機能の情報をクエリします。具体的な SQL ステートメントは次のとおりです。

SHOW VARIABLES LIKE '%slow%';
#以及
SHOW VARIABLES LIKE '%long_query_time%';

4.7 スロークエリログの削除

mysql> show variables like '%slow_query_log%';
+---------------------+----------------------------+
| Variable_name       | Value                      |
+---------------------+----------------------------+
| slow_query_log      | ON                         |
| slow_query_log_file | /var/lib/mysql/my-slow.log |
+---------------------+----------------------------+
2 rows in set (0.07 se

実行結果から、スロー クエリ ログのディレクトリはデフォルトで MySQL データ ディレクトリになっており、このディレクトリ内に存在する可能性があることがわかります手动删除慢查询日志文件。クエリ ログ ファイルを再生成するコマンドを使用しますmysqladmin flush-logs。具体的なコマンドは次のとおりです。実行後、スロー クエリ ログ ファイルがデータ ディレクトリに再生成されます。

# 不使用这个命令，没办法自己创建
mysqladmin -uroot -p flush-logs slow 

## 这个命令可以重置其他日志 例如undo日志

ヒント

スロークエリログは、mysqladmin flash-logs コマンドを使用して削除され、再構築されます。このコマンドを実行すると、スロー
クエリログは新しいログファイルにのみ存在するため、古いクエリログが必要な場合は、事前にバックアップする必要があることに注意してください。

5. SQL 実行コストの表示: SHOW PROFILE

Show profile については「論理アーキテクチャ」の章で説明されており、ここでは復習として記載します。

Show Profile は MySQL が提供するツールで、現在のセッションで SQL が何を行ったか、実行時のリソース消費量を分析し、SQL チューニングの測定に使用できます。默认情况下处于关闭状态、最新 15 件の実行結果を保存します。

この機能はセッションレベルで有効にできます

mysql> show variables like 'profiling';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling     | OFF   |
+---------------+-------+
1 row in set (0.34 sec)

次のように設定してプロファイルの表示をオンにしますprofiling='ON’。

mysql> set profiling = 'ON';
Query OK, 0 rows affected, 1 warning (0.06 sec)

mysql> show variables like 'profiling';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling     | ON    |
+---------------+-------+
1 row in set (0.13 sec)

次に、関連するクエリ ステートメントを実行します。次に、現在のセッションにどのようなプロファイルがあるかを確認するには、次のコマンドを使用します。

mysql> show profiles;
+----------+------------+-------------------------------------+
| Query_ID | Duration   | Query                               |
+----------+------------+-------------------------------------+
|        1 | 0.13515975 | show variables like 'profiling'     |
|        2 | 0.06386950 | select * from student_info limit 10 |
+----------+------------+-------------------------------------+
2 rows in set, 1 warning (0.01 sec)

現在のセッションには合計 2 つのクエリがあることがわかります。最新のクエリのコストを確認したい場合は、次を使用できます。

mysql> show profile;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.029330 |
| Executing hook on transaction  | 0.001174 |
| starting                       | 0.002804 |
| checking permissions           | 0.002918 |
| Opening tables                 | 0.009026 |
| init                           | 0.001605 |
| System lock                    | 0.000503 |
| optimizing                     | 0.000013 |
| statistics                     | 0.007651 |
| preparing                      | 0.000084 |
| executing                      | 0.005307 |
| end                            | 0.000017 |
| query end                      | 0.000178 |
| waiting for handler commit     | 0.000028 |
| closing tables                 | 0.001087 |
| freeing items                  | 0.000399 |
| cleaning up                    | 0.001748 |
+--------------------------------+----------+
17 rows in set, 1 warning (0.04 sec)

show profile for query 2また、クエリ結果が同じであるなど、指定したクエリ ID のコストを確認することもできます。SHOWPROFILE では、CPU、block.io などのさまざまな部分のオーバーヘッドを表示できます。

mysql> show profile cpu,block io for query 2;
+------------------------------+--------+----------+------------+-------------+
| Status                       |Duration| CPU_user |Block_ops_in|Block_ops_out|
+------------------------------+--------+----------+------------+-------------+
| starting                     |0.029330| 0.017180 |       49712|            0|
| Executing hook on transaction|0.001174| 0.001079 |        3624|            0|
| starting                     |0.002804| 0.002169 |        4728|            0|
| checking permissions         |0.002918| 0.002437 |        8168|            0|
| Opening tables               |0.009026| 0.005841 |       14120|            0|
| init                         |0.001605| 0.000392 |          80|            0|
| System lock                  |0.000503| 0.000130 |          24|            0|
| optimizing                   |0.000013| 0.000010 |           0|            0|
| statistics                   |0.007651| 0.003072 |        4160|            0|
| preparing                    |0.000084| 0.000071 |           0|            0|
| executing                    |0.005307| 0.001609 |         568|            0|
| end                          |0.000017| 0.000011 |           0|            0|
| query end                    |0.000178| 0.000047 |           8|            0|
| waiting for handler commit   |0.000028| 0.000025 |           0|            0|
| closing tables               |0.001087| 0.000279 |          56|            0|
| freeing items                |0.000399| 0.000259 |           8|            0|
| cleaning up                  |0.001748| 0.000381 |          56|            0|
+------------------------------+--------+----------+------------+-------------+
17 rows in set, 1 warning (0.01 sec)

実行が比較的長い場合は、コードが適切に記述されていない可能性があります。Explain を使用して問題のクエリを続けます。

ショー プロファイルの一般的なクエリ パラメータ:

① ALL: すべてのオーバーヘッド情報を表示します。

② BLOCK IO: ブロック IO のオーバーヘッドを表示します。

③ コンテキストスイッチ: コンテキストスイッチのオーバーヘッド。

④ CPU: CPU オーバーヘッド情報を表示します。

⑤ IPC: 送受信のオーバーヘッド情報を表示します。

⑥ MEMORY: メモリのオーバーヘッド情報を表示します。

⑦ PAGE FAULTS: ページエラーのオーバーヘッド情報を表示します。

⑧ SOURCE: Source_function、Source_file、Source_line に関するオーバーヘッド情報を表示します。

⑨ SWAPS: スワップ数のコスト情報を表示します。

日々の開発で注意を払う必要がある結論:

1. converting HEAP to MyISAM: クエリ結果が大きすぎるため、メモリが不足しており、データはディスクに移動されました。
2. creating tmp table:一時テーブルを作成します。まず一時テーブルにデータをコピーし、使用後に一時テーブルを削除します。
3. Copying to tmp table on disk:メモリ内の一時テーブルをディスクにコピーします。注意してください。
4. locked。
   上記の 4 つの結果のいずれかが show profile 診断結果に表示される場合は、SQL ステートメントを最適化する必要があります。

知らせ：

ただし、SHOW PROFILE コマンドは非推奨となり、information_schema のプロファイリング データ テーブルから表示できるようになります。

6. クエリ ステートメントを分析します: EXPLAIN

6.1 概要

**遅いクエリ SQL を特定したら、EXPLAIN ツールまたは DESCRIBE ツールを使用して、対象を絞った方法でクエリ ステートメントを分析できます。**DESCRIBE文の使い方はEXPLAIN文と同じであり、解析結果も同じです。

MySQL には SELECT ステートメントの最適化を特に担当するオプティマイザ モジュールがあり、その主な機能は、クライアントが要求したクエリに、最適と考えられるもの执行计划(最適なデータ取得方法と考えられるもの) を計算によって提供することです。システムに収集された統計情報を分析します。これは DBA が最適だと考えるものではない可能性があり、この部分が最も時間がかかります)。

この実行計画は、複数テーブルの接続順序は何か、クエリを具体的に実行するために各テーブルにどのようなアクセス方法が使用されるかなど、クエリを具体的に実行する方法を示します。MySQL は、EXPLAIN特定のクエリ ステートメントの特定の実行プランを表示するのに役立つステートメントを提供します。EXPLAINステートメントのさまざまな出力項目を理解することで、ターゲットを絞った方法でクエリ ステートメントのパフォーマンスを向上させることができます。

1.何ができるの？

• テーブルの読み取り順序
• データ読み取り操作の操作タイプ。
• 使用できるインデックス
• 実際に使用されるインデックス
• テーブル間の参照
• オプティマイザによってクエリされる各テーブルの行数

公式サイト紹介

https://dev.mysql.com/doc/refman/5.7/en/explain-output.html
https://dev.mysql.com/doc/refman/8.0/en/explain-output.html

バージョンステータス

• MySQL 5.6.3 より前では、EXPLAIN SELECT のみを使用できましたが、MYSQL 5.6.3 以降では使用できるようになりましたEXPLAIN SELECT。UPDATEDELETE
• 5.7 より前のバージョンでは、表示したい場合は コマンドをpartitions使用する必要があり、表示したい場合は コマンドを使用する必要があります。バージョン 5.7 以降では、Explain はデフォルトでパーティション内の情報を直接表示し、フィルター処理されます。explain partitionsfilteredexplain extended

6.2 基本的な構文

EXPLAIN または DESCRIBE ステートメントの構文は次のとおりです。

EXPLAIN SELECT select_options
# 或者 两个是一样的
DESCRIBE SELECT select_options

特定のクエリの実行プランを確認したい場合は、EXPLAIN次のように特定のクエリ ステートメントの前に 1 つを追加します。

mysql> EXPLAIN SELECT 1;

EXPLAINステートメントによって出力される各列の機能は次のとおりです。

リスト	説明する
ID	大規模なクエリ ステートメントでは、各 SELECT キーワードが一意の ID に対応します。
選択タイプ	SELECT キーワードに対応するクエリの種類
テーブル	テーブル名
パーティション	一致するパーティション情報
タイプ	単一テーブルへのアクセス方法(重要)
possible_keys	可能なインデックス
鍵	実際に使用されるインデックス
key_len	実際に使用されるインデックスの長さ
参照	インデックス列等価クエリを使用すると、インデックス列と一致するオブジェクト情報が等価になります。
行	読み取られるレコードの推定数
フィルタリングされた	検索条件によるフィルタリング後にテーブルに残っているレコードの割合
余分な	追加情報

6.3 データの準備

1. テーブルを作成する

CREATE TABLE s1 (
	id INT AUTO_INCREMENT,
	key1 VARCHAR(100), 
	key2 INT, 
	key3 VARCHAR(100), 
	key_part1 VARCHAR(100),
	key_part2 VARCHAR(100),
	key_part3 VARCHAR(100),
	common_field VARCHAR(100),
	PRIMARY KEY (id),
	INDEX idx_key1 (key1),
	UNIQUE INDEX idx_key2 (key2),
	INDEX idx_key3 (key3),
	INDEX idx_key_part(key_part1, key_part2, key_part3)
) ENGINE=INNODB CHARSET=utf8;

CREATE TABLE s2 (
    id INT AUTO_INCREMENT,
    key1 VARCHAR(100),
    key2 INT,
    key3 VARCHAR(100),
    key_part1 VARCHAR(100),
    key_part2 VARCHAR(100),
    key_part3 VARCHAR(100),
    common_field VARCHAR(100),
    PRIMARY KEY (id),
    INDEX idx_key1 (key1),
    UNIQUE INDEX idx_key2 (key2),
    INDEX idx_key3 (key3),
	INDEX idx_key_part(key_part1, key_part2, key_part3)
) ENGINE=INNODB CHARSET=utf8;

2. パラメータlog_bin_trust_function_creatorsを設定します。

関数を作成します。エラーが報告された場合は、次のコマンドを有効にする必要があります: 関数設定の作成を許可:

set global log_bin_trust_function_creators=1; # 不加global只是当前窗口有效。

3. 関数の作成

DELIMITER //
CREATE FUNCTION rand_string1 ( n INT ) 
	RETURNS VARCHAR ( 255 ) #该函数会返回一个字符串
BEGIN
	DECLARE
		chars_str VARCHAR ( 100 ) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ';
	DECLARE
		return_str VARCHAR ( 255 ) DEFAULT '';
	DECLARE
		i INT DEFAULT 0;
	WHILE
			i < n DO
			
			SET return_str = CONCAT(
				return_str,
			SUBSTRING( chars_str, FLOOR( 1+RAND ()* 52 ), 1 ));
		
		SET i = i + 1;
		
	END WHILE;
	RETURN return_str;
	
END // 
DELIMITER ;

4. ストアド プロシージャを作成する

s1 テーブルにデータを挿入するストアド プロシージャを作成します。

DELIMITER //
CREATE PROCEDURE insert_s1 (IN min_num INT (10),IN max_num INT (10))
BEGIN
    DECLARE i INT DEFAULT 0;
    SET autocommit = 0;
    REPEAT
    SET i = i + 1;
    INSERT INTO s1 VALUES(
    (min_num + i),
    rand_string1(6),
    (min_num + 30 * i + 5),
    rand_string1(6),
    rand_string1(10),
    rand_string1(5),
    rand_string1(10),
    rand_string1(10));
    UNTIL i = max_num
    END REPEAT;
    COMMIT;
END //
DELIMITER ;

s2 テーブルにデータを挿入するストアド プロシージャを作成します。

DELIMITER //
CREATE PROCEDURE insert_s2 (IN min_num INT ( 10 ),IN max_num INT ( 10 )) 
BEGIN
	DECLARE i INT DEFAULT 0;
	SET autocommit = 0;
	REPEAT
 	SET i = i + 1;
		INSERT INTO s2 VALUES(
				( min_num + i ),
				rand_string1 ( 6 ),
				( min_num + 30 * i + 5 ),
				rand_string1 ( 6 ),
				rand_string1 ( 10 ),
				rand_string1 ( 5 ),
				rand_string1 ( 10 ),
				rand_string1 ( 10 ));
		UNTIL i = max_num 
	END REPEAT;
	COMMIT;
	
END // 
DELIMITER ;

5. ストアド プロシージャを呼び出す

s1 テーブル データの追加: 10,000 レコードの追加:

CALL insert_s1(10001,10000); # id 10002~20001

s2 テーブル データの追加: 10,000 レコードの追加:

CALL insert_s2(10001,10000);# id 10002~20001

6.4 各EXPLAIN列の機能

皆様により良いエクスペリエンスを提供するために、EXPLAIN出力列の順序を調整しました。

1.テーブル

テーブル名

クエリ ステートメントがどれほど複雑であっても、包含了多少个表最終的には各テーブルに対して実行する必要がある单表访问ため、
MySQLでは、 EXPLAIN ステートメントによって出力される各レコードが 1 つのテーブルのアクセス メソッドに対応することを規定しています。このレコードのテーブルとカラム
テーブルのテーブル名を表します（実際のテーブル名ではない場合もあります。省略される場合もあります）。

#1. table：表名
#查询的每一行记录都对应着一个单表
explain select count(*) from s1;

#s1:驱动表  s2:被驱动表
EXPLAIN SELECT * FROM s1 INNER JOIN s2;
# 驱动表和被驱动表是 优化器决定的，他认为哪个比较好久用哪个

使用されるテーブルの数、レコードの数

2.ID

通常、選択と ID は 1 つずつありますが、例外があり、クエリ オプティマイザーによって最適化されています。

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';

mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2;

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a';

クエリオプティマイザーの最適化

 ######查询优化器可能对涉及子查询的查询语句进行重写,转变为多表查询的操作########
 EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field = 'a');

実行結果: クエリ オプティマイザーによって最適化されているため、ID は 1 つだけです。

ユニオン重複排除

当初は 1 つの選択と 1 つの ID を考えていましたが、予想は 2 つでした。

 #Union去重
# union 去重，union all 不去重
EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

# union all 不去重  所以不需要放在临时表里面
mysql> EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2;

まとめ：

• ID が同じ場合はグループとみなされ、上から下へ順番に実行されます。
• すべてのグループにおいて、id 値が大きいほど優先度が高く、最初に実行されます。
• 注意点: 各 ID 番号は独立したクエリを表しており、SQL ステートメント内のクエリの数は少ないほど良いです。

3. タイプの選択

大きなクエリ ステートメントには複数の SELECT キーワードを含めることができ、每个SELECT关键字代表着一个小的查询语句各 SELECT キーワードの FROM 句には複数のテーブルを含めることができます (これらのテーブルは接続クエリに使用されます)。每一张表都对应着执行计划输出中的一条记录同じ SELECT キーワードの場合、 のテーブルの ID 値は同じ。

MySQL では、SELECT キーワードで表される小さなクエリごとに呼び出される属性が定義されていますselect_type。つまり、特定の小さなクエリの値がわかっていればselect_type属性、これがわかるということです。どのような値を取り得るか小查询在整个大查询中扮演了一个什么角色を見てみましょう
select_type。公式を参照してください。ドキュメンテーション ：

名前	説明する
単純	単純な SELECT (UNION やサブクエリを使用しない)
主要な	最外側のSELECT
連合	UNION 内の 2 番目以降の SELECT ステートメント
組合結果	UNION の結果
サブクエリ	サブクエリ内の最初の SELECT
従属サブクエリ	サブクエリ内の最初の SELECT (外部クエリに依存)
従属組合	UNION 内の 2 番目以降の SELECT ステートメント (外部クエリに依存)
派生	派生テーブル
物質化された	マテリアライズドサブクエリ
キャッシュ不能なサブクエリ	結果をキャッシュできず、外部クエリの行ごとに再評価する必要があるサブクエリ
キャッシュできないユニオン	キャッシュ不可能なサブクエリに属する​​ UNION 内の 2 番目以降の選択 (UNCACHEABLE SUBQUERY を参照)

• SIMPLE

   # 查询语句中不包含`UNION`或者子查询的查询都算作是`SIMPLE`类型
   EXPLAIN SELECT * FROM s1;
   
    #连接查询也算是`SIMPLE`类型
   EXPLAIN SELECT * FROM s1 INNER JOIN s2;
  

• PRIMARYそしてUNION_UNION RESULT

  • UNION RESULT

    MySQL はクエリの重複排除を完了するために一時テーブルの使用を選択しますUNION。この一時テーブルのクエリは上の例に示すselect_typeとおりです。UNION RESULT

  #对于包含`UNION`或者`UNION ALL`或者子查询的大查询来说，它是由几个小查询组成的，其中最左边的那个
  #查询的`select_type`值就是`PRIMARY`
   
  #对于包含`UNION`或者`UNION ALL`的大查询来说，它是由几个小查询组成的，其中除了最左边的那个小查询
  #以外，其余的小查询的`select_type`值就是`UNION`
  
  #`MySQL`选择使用临时表来完成`UNION`查询的去重工作，针对该临时表的查询的`select_type`就是`UNION RESULT` 	
  

  SQLをテストします:

   EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;	
  

EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2;

• SUBQUERY

  サブクエリを含むクエリ ステートメントを対応するsemi-join形式に変換できず、そのサブクエリが無関係なサブクエリであり、クエリ オプティマイザが実体化スキームを使用してサブクエリを実行することを決定した場合、サブクエリのSELECTキーワードで表されるクエリは、たとえば、次のクエリ:
  select_typeSUBQUERY

   #子查询：
   #如果包含子查询的查询语句不能够转为对应的`semi-join`的形式，并且该子查询是不相关子查询。
   #该子查询的第一个`SELECT`关键字代表的那个查询的`select_type`就是`SUBQUERY`
   EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a';
  

• DEPENDENT SUBQUERY

  依存サブクエリ

   #如果包含子查询的查询语句不能够转为对应的`semi-join`的形式，并且该子查询是相关子查询，
   #则该子查询的第一个`SELECT`关键字代表的那个查询的`select_type`就是`DEPENDENT SUBQUERY`
   EXPLAIN SELECT * FROM s1 
   WHERE key1 IN (SELECT key1 FROM s2 WHERE s1.key2 = s2.key2) OR key3 = 'a';
   #注意的是，select_type为`DEPENDENT SUBQUERY`的查询可能会被执行多次。
  

• DEPENDENT UNION

   #在包含`UNION`或者`UNION ALL`的大查询中，如果各个小查询都依赖于外层查询的话，那除了
   #最左边的那个小查询之外，其余的小查询的`select_type`的值就是`DEPENDENT UNION`。
   EXPLAIN SELECT * FROM s1 
   WHERE key1 IN (SELECT key1 FROM s2 WHERE key1 = 'a' UNION SELECT key1 FROM s1 WHERE key1 = 'b');
   
   # 这里优化器会重构成exist
  

• DERIVED

  派生：派生、派生

   #对于包含`派生表`的查询，该派生表对应的子查询的`select_type`就是`DERIVED`
   EXPLAIN SELECT * 
   FROM (SELECT key1, COUNT(*) AS c FROM s1 GROUP BY key1) AS derived_s1 WHERE c > 1;
  

  

• MATERIALIZED

  materialized: 英 [məˈtɪəri:əˌlaɪzd] 具体化

  #当查询优化器在执行包含子查询的语句时，选择将子查询物化之后与外层查询进行连接查询时，
  #该子查询对应的`select_type`属性就是`MATERIALIZED`
  EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2); #子查询被转为了物化表 
  
  

  

  理解できません: なぜ上記のサブクエリには原子化がないのですか?

  EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a';
  # 这个怎么不物化
  

• UNCACHEABLE SUBQUERY

  キャッシュできない

• UNCACHEABLE UNION

4. パーティション (オプション)

• パーティション化されたテーブルのヒット状況を表します。パーティション化されていないテーブルの場合、この項目は NULL になります。通常の状況では、クエリ ステートメントの実行プランのパーティション列の値は NULL です。
• https://dev.mysql.com/doc/refman/5.7/en/alter-table-partition-operations.html
• さらに詳しく知りたい場合は、次のようにテストできます。パーティションテーブルを作成します。

-- 创建分区表，
-- 按照id分区，id<100 p0分区，其他p1分区
CREATE TABLE user_partitions (
    id INT auto_increment,
    NAME VARCHAR(12),PRIMARY KEY(id))
    PARTITION BY RANGE(id)(
    PARTITION p0 VALUES less than(100),
    PARTITION p1 VALUES less than MAXVALUE
);

DESC SELECT * FROM user_partitions WHERE id>200;

ID が 200 より大きい (200>100、p1 パーティション) レコードをクエリし、実行プランを表示します。パーティションは p1 であり、パーティション ルールに準拠しています。

5.タイプ☆

実行プランのレコードは、特定のテーブルへの MySQL のアクセス执行查询时的访问方法(「アクセス タイプ」とも呼ばれます) を表します。typeその中の列は、アクセス方法が何であるかを示します。これはより重要な指標です。たとえば、type列値 が表示されるとref、MySQL がrefそのアクセス メソッドを使用してs1テーブルに対してクエリを実行しようとしていることを示します。

完全なアクセス方法は次のとおりです。system、const、eq_ref、ref、、、、、、。fulltextref_or_nullindex_mergeunique_subqueryindex_subqueryrangeindexALL

詳しく説明しましょう:

• system

  只有一条记录テーブル内の統計とテーブルで使用されるストレージ エンジン (MyISAM やメモリなど) が正確な場合、テーブルへのアクセス方法は ですsystem。たとえば、新しいMyISAMテーブルを作成し、そこにレコードを挿入してみましょう。

  mysql> CREATE TABLE t(i int) Engine=MyISAM;
  Query OK, 0 rows affected (0.05 sec)
  
  mysql> INSERT INTO t VALUES(1);
  Query OK, 1 row affected (0.01 sec)
  

  次に、このテーブルにクエリを実行するための実行プランを確認します。

  mysql> EXPLAIN SELECT * FROM t;
  +----+-------------+-------+------------+--------+
  | id | select_type | table | partitions | type   |
  +----+-------------+-------+------------+--------+
  |  1 | SIMPLE      | t     | NULL       | system |
  +----+-------------+-------+------------+--------+
  1 row in set, 1 warning (0.00 sec)
  

  innodb の場合、innodb システムは数値フィールドを保存しないため、ALL になります。。MyISAM はそのようなフィールドを保存します

• const

   #当我们根据主键或者唯一二级索引列与常数进行等值匹配时，对单表的访问方法就是`const`
   EXPLAIN SELECT * FROM s1 WHERE id = 10005;
   
   EXPLAIN SELECT * FROM s1 WHERE key2 = '10066';
  

• eq_ref

   #在连接查询时，如果被驱动表是通过主键或者唯一二级索引列等值匹配的方式进行访问的
   #（如果该主键或者唯一二级索引是联合索引的话，所有的索引列都必须进行等值比较），则
   #对该被驱动表的访问方法就是`eq_ref`
   EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id;
   
  

  mysql>  EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id;
  +----+------------+------+--------+---------+---------+------------------+------+
  | id | select_type| table| type   | key     | key_len | ref              | rows |
  +----+------------+------+--------+---------+---------+------------------+------+
  |  1 | SIMPLE     | s1   | ALL    | NULL    | NULL    | NULL             | 9895 |
  |  1 | SIMPLE     | s2   | eq_ref | PRIMARY | 4       | atguigudb1.s1.id |    1 |
  +----+------------+------+--------+---------+---------+------------------+------+
  2 rows in set, 1 warning (0.00 sec)
  

  実行計画の結果から、MySQL は s2 を駆動テーブルとして、s1 を被駆動テーブルとして使用するつもりであることがわかります。s1 のアクセス方法に注目し
  、eq_refs1 テーブルにアクセスするときに通过主键的等值匹配アクセスできることを示しています。

• ref

   #当通过普通的二级索引列与常量进行等值匹配时来查询某个表，那么对该表的访问方法就可能是`ref`
   EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';
  

  結果:

  mysql>  EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';
  +----+-------+------+---------------+----------+---------+
  | id | table | type | possible_keys | key      | key_len |
  +----+-------+------+---------------+----------+---------+
  |  1 | s1    | ref  | idx_key1      | idx_key1 | 303     |
  +----+-------+------+---------------+----------+---------+
  1 row in set, 1 warning (0.00 sec)
  

  ヒント: インデックス作成は、型が同じ場合にのみ実行できます。

  EXPLAIN SELECT * FROM s1 WHERE key2 = 10066;
  # 这个是不会走索引的 因为key2 是字符串
  # 类型不一样，mysql会加函数，进行隐式转换，一旦加上函数，就不会走索引了。
  

• fulltext

  全文インデックス

• ref_or_null

   #当对普通二级索引进行等值匹配查询，该索引列的值也可以是`NULL`值时，那么对该表的访问方法
   #就可能是`ref_or_null`
   EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key1 IS NULL;
  

• index_merge

   #单表访问方法时在某些场景下可以使用`Intersection`、`Union`、
   #`Sort-Union`这三种索引合并的方式来执行查询
   EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';
  

  結果

  mysql>  EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';
  +---+-------+------------+-------------------+--------+-------------------------------+
  | id| table | type       | key               | key_len| Extra
  +---+-------+------------+-------------------+--------+-------------------------------+
  |  1| s1    | index_merge| idx_key1,idx_key3 | 303,303| Using union(idx_key1,idx_key3)|
  +---+-------+------------+-------------------+--------+-------------------------------+
  1 row in set, 1 warning (0.01 sec)
  
  

  実行プランのtypeカラムの値からindex_merge、MySQL がインデックス マージを使用してテーブル
  に対してクエリを実行する予定であることがわかります。s1

• unique_subquery

   #`unique_subquery`是针对在一些包含`IN`子查询的查询语句中，如果查询优化器决定将`IN`子查询
   #转换为`EXISTS`子查询，而且子查询可以使用到主键进行等值匹配的话，那么该子查询执行计划的`type`
   #列的值就是`unique_subquery`
   EXPLAIN SELECT * FROM s1 
   WHERE key2 IN (SELECT id FROM s2 WHERE s1.key1 = s2.key1) OR key3 = 'a';
  

• index_subquery

  EXPLAIN SELECT * FROM s1 WHERE common_field IN (SELECT key3 FROM s2 where
  s1.key1 = s2.key1) OR key3 = 'a';
  

• range

  #如果使用索引获取某些`范围区间`的记录，那么就可能使用到`range`访问方法
  EXPLAIN SELECT * FROM s1 WHERE key1 IN ('a', 'b', 'c');
  
  #同上
  EXPLAIN SELECT * FROM s1 WHERE key1 > 'a' AND key1 < 'b';
  

• index

  #当我们可以使用索引覆盖，但需要扫描全部的索引记录时，该表的访问方法就是`index`
  EXPLAIN SELECT key_part2 FROM s1 WHERE key_part3 = 'a';
  

  インデックスカバレッジ、INDEX idx_key_part(key_part1, key_part2, key_part3）これら 3 つが複合インデックスを構成します

  key_part3 は複合インデックス内にあり、クエリされたフィールドもインデックス内にあります。インデックスを直接走査するだけで、データを見つけることができます。

  考え方: 利点は、インデックスに保存されるデータが少なくなり、データが少ないということはページが少なくなり、IO を削減できることです。

• ALL

mysql> EXPLAIN SELECT * FROM s1;

一般に、Allこのアクセス方法を除くすべてのアクセス方法でインデックスを使用できますがindex_merge、このアクセス方法を除くすべてのアクセス方法で使用できるインデックスは最大 1 つだけです。

まとめ：

結果として得られる値は、最良から最悪まで次のようになります。

システム > const > eq_ref > ref >

フルテキスト > ref_or_null > インデックスマージ > ユニークサブクエリ > インデックスサブクエリ > 範囲 >

インデックス > すべて

SQL パフォーマンス最適化の目標: 少なくとも range レベルに達すること。要件は ref レベル、できれば consts レベルです。(
Alibaba 開発マニュアルで必須)

6. possible_keysとkey

EXPLAIN ステートメントによって出力される実行プランでは、列はpossible_keys、特定のクエリ ステートメント内の特定のテーブルに対して单表查询时可能用どのインデックスが実行されるかを示します。一般的なクエリに関係するフィールドにインデックスが存在する場合、そのインデックスはリストされますが、クエリでは使用されない場合があります。key列によって表される实际用到インデックスは何ですか? NULL の場合、インデックスは使用されません。たとえば、次のクエリについて考えてみましょう。

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key3 = 'a';

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key3 = 'a';
+----+-------------+------+------+-------------------+----------+
| id | select_type | table| type | possible_keys     | key      |
+----+-------------+------+------+-------------------+----------+
|  1 | SIMPLE      | s1   | ref  | idx_key1,idx_key3 | idx_key3 |
+----+-------------+------+------+-------------------+----------+
1 row in set, 1 warning (0.01 sec)

上記の実行プランの possible_keys 列の値はidx_key1,idx_key3、クエリで2 つのインデックスを使用できることを示し、key 列の値は、idx_key1クエリオプティマイザーが異なるインデックスを使用するコストを計算した後、最終的にインデックスを使用することを決定することを示します。idx_key3idx_key3idx_key3

使用できるインデックスは 1 つだけです。したがって、彼は 1 つを選択して使用する必要があります。上記を見るとindex_merge 、インデックスのマージが行われます。

7.キーレン☆

• key_len: 使用される実際のインデックスの長さ (つまり、バイト数)

• key_len が小さいほど、インデックス作成の効果が高くなります。これは以前に学習したことですが、key_len が短いほど効率的です。

• ただし、ジョイント インデックスでは、key_len に長さを加えた値が 1 回ヒットされます。値が長いほど精度が高く、効果が高くなります。

#7. 
EXPLAIN SELECT * FROM s1 WHERE id = 10005;

## 结果key_len =4

mysql> EXPLAIN SELECT * FROM s1 WHERE key2 = 10126;

## 结果key_len = 5

key2 は int 型の一意のインデックスです。。null 値も存在する可能性があるため、null がフィールドを占有します。4+1 = 5

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';

## 结果key_len = 303 

理由: idx_key_part(key_part1, key_part2, key_part3）3 つの 100 フィールドの合計です。各フィールドは空にすることができるため、101*3 = 303

mysql> EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a';
+----+------------+------+---------------+--------------+---------+-------+------+
| id | select_type| type | possible_keys | key          | key_len | ref   | rows |
+----+------------+------+---------------+--------------+---------+-------+------+
|  1 | SIMPLE     | ref  | idx_key_part  | idx_key_part | 303     | const |    1 |
+----+------------+------+---------------+--------------+---------+-------+------+
1 row in set, 1 warning (0.00 sec)

結果の key_len は 303 です

mysql> EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b';
+----+------------+-----+---------------+--------------+---------+------------
| id | select_type|type | possible_keys | key          | key_len | ref        
+----+------------+-----+---------------+--------------+---------+------------
|  1 | SIMPLE     |ref  | idx_key_part  | idx_key_part | 606     | const,const
+----+------------+-----+---------------+--------------+---------+------------
1 row in set, 1 warning (0.00 sec)

結果キー_606

ここではジョイント インデックスが 2 回ヒットされ、精度と効果が向上します。

練習する：

key_len の長さの計算式:

varchar(10)变长字段且允许NULL = 10 * ( character set：utf8=3,gbk=2,latin1=1)+1(NULL)+2(变长字段)

varchar(10)变长字段且不允许NULL = 10 * ( character set：utf8=3,gbk=2,latin1=1)+2(变长字段)

char(10)固定字段且允许NULL = 10 * ( character set：utf8=3,gbk=2,latin1=1)+1(NULL)

char(10)固定字段且不允许NULL = 10 * ( character set：utf8=3,gbk=2,latin1=1)

8.参考文献

# 8. ref：当使用索引列等值查询时，与索引列进行等值匹配的对象信息。
#比如只是一个常数或者是某个列。
 
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';
+----+-------------+------+------+---------------+----------+---------+-------+
| id | select_type | table| type | possible_keys | key      | key_len | ref   |
+----+-------------+------+------+---------------+----------+---------+-------+
|  1 | SIMPLE      | s1   | ref  | idx_key1      | idx_key1 | 303     | const |
+----+-------------+------+------+---------------+----------+---------+-------+

型は type =ref であり、const (定数) と比較されます。

mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id;
+---+------+--------+---------------+--------+------------------+-----
| id| table| type   | possible_keys | key    | ref              | rows
+---+------+--------+---------------+--------+------------------+-----
|  1| s1   | ALL    | PRIMARY       | NULL   | NULL             | 9895
|  1| s2   | eq_ref | PRIMARY       | PRIMARY| atguigudb1.s1.id |    1
+---+------+--------+---------------+--------+------------------+-----

タイプは type =eq_ref です (atguigudb1.s1.id と比較)

mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s2.key1 = UPPER(s1.key1);                         
+----+------+------+---------------+----------+---------+------+------+----------------------+
| id | table| type | possible_keys | key      | key_len | ref  | rows |Extra                 |
+----+------+------+---------------+----------+---------+------+------+----------------------+
|  1 | s1   | ALL  | NULL          | NULL     | NULL    | NULL | 9895 |NULL                  |
|  1 | s2   | ref  | idx_key1      | idx_key1 | 303     | func |    1 |Using index condition |
+----+------+------+---------------+----------+---------+------+------+----------------------+

メソッドと比較するfunc

9.行☆

 # 9. rows：预估的需要读取的记录条数
 # `值越小越好`
 # 通常与filtered 一起使用
 EXPLAIN SELECT * FROM s1 WHERE key1 > 'z';

rows の値が小さいほど、データが 1 ページに収まる可能性が高く、io は小さくなります。

10. フィルタリング済み

大きければ大きいほどいい

filtered の値は、読み取る必要がある行のうち、結果を返す行の割合 (行列の値) を指します。

私自身の理解: たとえば、100 行を読み取った後、filtered は 10% となり、100 行をフィルターする必要があることを意味します。。。。。。。。。これは私自身の猥褻さから全く根拠のないことなので、このようにしか理解できません。

インデックスによって実行される単一テーブル スキャンを使用している場合、計算するときに、対応するインデックスを使用する検索条件以外の他の検索条件を満たすレコードの数を見積もる必要があります。

 EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND common_field = 'a';

単一テーブルのクエリの場合、このフィルターされた列の値は意味がありません。この値更关注在连接查询中驱动表对应的执行计划记录的filtered值は、駆動テーブルが実行される回数を決定します (つまり、行数 * フィルターされた列)。

EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key1 WHERE s1.common_field = 'a';

11.おまけ☆

名前が示すように、Extra列は、他の列での表示には適さないが非常に重要な追加情報など、追加情報を記述するために使用されます。この追加情報を使用できます更准确的理解MySQL到底将如何执行给定的查询语句。MySQL によって提供される追加情報が多数ありますので、その要点を見てみましょう。

• No tables used

  この追加情報は、次のようにクエリ ステートメントに FROM 句がない場合にプロンプ​​トが表示されます。

mysql> EXPLAIN SELECT 1;				

• Impossible WHERE

クエリ ステートメントの句はWHERE常にFALSEtimeこの追加情報が求められます

mysql> EXPLAIN SELECT * FROM s1 WHERE 1 != 1;

• where の使用

  フルテーブルスキャンを使用して特定のテーブルに対してクエリを実行し、WHEREステートメントの句にテーブルの検索条件がある場合、Extra上記の追加情報が列に表示されます。

EXPLAIN SELECT * FROM s1 WHERE common_field = 'a';

インデックス以外の条件がある場合にも、このプロンプトが表示されます。

 #当使用索引访问来执行对某个表的查询，并且该语句的`WHERE`子句中
 #有除了该索引包含的列之外的其他搜索条件时，在`Extra`列中也会提示上述额外信息。
 explain SELECT * FROM s1 WHERE key1 = 'fUhcQU' and  common_field = 'uDHCOnalcF';

• No matching min/max row

クエリ リストに集計関数が存在するがMIN、句内の検索条件に一致するレコードMAXがない場合WHERE、この追加情報が求められます。

 # 数据库不存在 QLjKYOx
 EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'QLjKYOx';

 # 数据库存在 QLjKYO
 EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'QLjKYO';

• Using index

クエリ リストと検索条件に特定のインデックスに属する列のみが含まれている場合、つまり、カバー インデックスを使用できる場合は、Extra列に関する追加情報の入力を求めるプロンプトが表示されます。

たとえば、次のクエリは使用するだけで済みidx_key1、テーブルを返す操作は必要ありません。

EXPLAIN SELECT key1 FROM s1 WHERE key1 = 'a';

• Using index condition

  一部の検索条件には索引列が表示されますが、索引を使用してコースウェアを表示し、索引条件を理解することはできません。

  SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a';
  mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a';
  

ステップ 1. ここで、key1 > 'z' はインデックスを調べ、378 個のデータを見つけました。。。

ステップ 2. key1 LIKE '%b'; この条件はまだ key1 インデックスであるため、次に必要なのはこれら 378 個のインデックスを走査することだけです。'%a' に一致するものはどれですか

ステップ 3. ステップ 2 を通じて有効なインデックスをフィルタリングして除外します。。これはインデックスの使用条件です。

ステップ 4. テーブルをクエリするための条件を満たすインデックスを返します。

完全な説明：

インデックスkey1 > 'z'は使用できますが、key1 LIKE '%a 'インデックスは使用できません。以前のバージョンの MySQL では、このクエリは次の手順に従って実行されました。

• まず、条件 key1 > 'z' に従って、idx_key1セカンダリ インデックスから対応するセカンダリ インデックス レコードを取得します。
• 前の手順で取得したセカンダリ インデックス レコードの主キー値に基づいてテーブルに戻り、完全なユーザー レコードを見つけて、レコードがkey1 LIKE '%a'この条件を満たしているかどうかを確認し、修飾されたレコードを最終的な結果セットに追加します。

ただし、アクセス メソッドの実行にkey1 LIKE ‘%a'参加するように範囲間隔を形成することはできませんが、この条件には結局のところカラムのみが関係するため、MySQL では上記の手順が改善されました。rangekey1

• まず、key1 > 'z'この条件に基づいて、idx_key1セカンダリ インデックス内の対応するセカンダリ インデックス レコードを見つけます。

• 指定されたセカンダリ インデックス レコードについては、急いでテーブルに戻すのではなく、まずレコードがkey1 LIKE ‘%a'この条件を満たしているかどうかを確認します。この条件を満たしていない場合は、セカンダリ インデックス レコードをテーブルに戻す必要はありません。

• この条件を満たすセカンダリ インデックス レコードに対してkey1 LIKE '%a'テーブルの戻り操作を実行します。

テーブルの戻り操作は実際にはランダム IO であり、比較的時間がかかるため、上記の変更はわずかな改善にとどまりますが、テーブルの戻り操作にかかるコストを大幅に節約できます。MySQL ではこれを改良索引条件下推(英語名: Index Condition Pushdown) と呼んでいます。この機能がクエリ ステートメントの実行中に使用される場合は索引条件下推、[追加] 列に表示されます。Using index condition

• Using join buffer (Block Nested Loop)

  インデックスのないフィールドはテーブルに関連付けられます。

  結合クエリの実行中、駆動テーブルがアクセスを高速化するためにインデックスを効果的に使用できない場合、MySQL は通常、join bufferクエリを高速化するためにその名前のメモリ ブロックを割り当てます。これが私たちが話していることです。基于块的嵌套循环算法

  mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.common_field = s2.common_field;
  

• Not exists

  左 (外部) 結合を使用する場合、WHERE句にNULLドリブン テーブルの列が値と等しいことを要求する検索条件が含まれており、その列にNULL値を格納することが許可されていない場合、実行の Extra 列にテーブルの計画Not exists追加情報を

  EXPLAIN SELECT * FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.id IS NULL;
  # 都表关联了，，关联字段怎么会等于 is null
  

  

• Using intersect(...) 、 Using union(...) 和 Using sort_union(...)

  • 実行計画列Extraにプロンプ​​トが表示された場合は、インデックスをUsing intersect(...)使用する準備ができていることを意味します。Intersect

  • マージによってクエリを実行します。括弧内の名前は、...マージする必要があるインデックス名を示します。

  • プロンプトが表示された場合は、インデックスの結合を使用してクエリを実行するUsing union(...)準備ができていることを意味します。Union

  • インデックスの結合を使用してクエリを実行することUsing sort_union(...)を示すプロンプトが表示されます。Sort-Union

     EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';
    

    

• Zero limit

• Using filesort

  場合によっては、次のクエリのように、インデックスを使用して結果セット内のレコードを並べ替えることができます。

  EXPLAIN SELECT * FROM s1 ORDER BY key1 LIMIT 10;
  

  このクエリ ステートメントでは、idx_key1インデックスを使用して key1 列の 10 レコードを直接取得し、テーブル操作を実行できます。ただし、多くの場合、ソート操作ではインデックスを使用できず、メモリ内 (レコードが少ない場合) またはディスク上 (レコードが多い場合) でのみソートできます。MySQL は、メモリ内またはディスク上でソートするこの方法を使用します。ディスク. ファイルソート（英語名：filesort）と総称される。クエリでファイルの並べ替えを実行する必要がある場合、実行プランの [追加] 列にUsing filesortプロンプ​​トが表示されます。

  EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10;
  

• Using temporary

  多くのクエリの実行中、MySQL は重複排除やソートなどの一部の機能を完了するために一時テーブルを使用することがあります。たとえば、、、、その他の句を含む多くのクエリを実行するとき、完了時DISTINCTに 内部一時テーブルがクエリで使用されている場合、実行計画列にプロンプ​​トが表示されます。GROUP BYUNIONExtraUsing temporary

   EXPLAIN SELECT DISTINCT common_field FROM s1;
   
  

 #执行计划中出现`Using temporary`并不是一个好的征兆，因为建立与维护临时表要付出很大成本的，所以
 #我们`最好能使用索引来替代掉使用临时表`。比如：扫描指定的索引idx_key1即可
 EXPLAIN SELECT key1, COUNT(*) AS amount FROM s1 GROUP BY key1;

12. まとめ

• EXPLAIN はさまざまなキャッシュを考慮しません
• EXPLAIN は、クエリの実行時に MySQL によって行われた最適化作業を表示できません
• EXPLAIN では、トリガー、ストアド プロシージャ、またはユーザー定義関数がクエリに与える影響については説明しません。
• 一部の統計は推定値であり、正確な値ではありません

7. EXPLAIN のさらなる使用

7.1 4 つの出力形式について説明する

EXPLAIN の出力形式について説明します。传统格式EXPLAIN は、 、JSON格式、TREE格式の4 つの形式を出力できます可
视化输出。ユーザーはニーズに応じて自分に合った形式を選択できます。

1. 従来のフォーマット

従来の形式はシンプルで簡単で、出力はクエリ プランを要約したテーブルになります。

mysql> EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE
s2.common_field IS NOT NULL;  
+----+-------------+-------+------------+------+---------------+-------
| id | select_type | table | partitions | type | possible_keys | key   
+----+-------------+-------+------------+------+---------------+-------
|  1 | SIMPLE      | s2    | NULL       | ALL  | idx_key1      | NULL  
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key1      | idx_ke
+----+-------------+-------+------------+------+---------------+-------
2 rows in set, 1 warning (0.00 sec)

2.JSON形式

最初の形式で導入されたステートメント出力EXPLAINには、実行計画の品質を測定する重要な属性が欠けています成本。JSON形式は、最详尽的格式実行コスト情報を含む4つの形式の出力情報です。

• JSON 形式: EXPLAIN ワードと実際のクエリ ステートメントの間に追加しますFORMAT=JSON。

  EXPLAIN FORMAT=JSON SELECT ....  
  

• EXPLAIN のカラムと JSON の対応: (MySQL 5.7 ドキュメントより)
  

このようにして、次のようなプランのコストを含む実行プランを json 形式で取得できます。

mysql> EXPLAIN FORMAT=JSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a' \G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "1360.07"
    },
    "nested_loop": [
      {
        "table": {
          "table_name": "s1",
          "access_type": "ALL",
          "possible_keys": [
            "idx_key1"
          ],
          "rows_examined_per_scan": 9895,
          "rows_produced_per_join": 989,
          "filtered": "10.00",
          "cost_info": {
            "read_cost": "914.80",
            "eval_cost": "98.95",
            "prefix_cost": "1013.75",
            "data_read_per_join": "1M"
          },
          "used_columns": [
            "id",
            "key1",
            "key2",
            "key3",
            "key_part1",
            "key_part2",
            "key_part3",
            "common_field"
          ],
          "attached_condition": "((`atguigudb1`.`s1`.`common_field` = 'a') and (`atguigudb1`.`s1`.`key1` is not null))"
        }
      },
      {
        "table": {
          "table_name": "s2",
          "access_type": "eq_ref",
          "possible_keys": [
            "idx_key2"
          ],
          "key": "idx_key2",
          "used_key_parts": [
            "key2"
          ],
          "key_length": "5",
          "ref": [
            "atguigudb1.s1.key1"
          ],
          "rows_examined_per_scan": 1,
          "rows_produced_per_join": 989,
          "filtered": "100.00",
          "index_condition": "(cast(`atguigudb1`.`s1`.`key1` as double) = cast(`atguigudb1`.`s2`.`key2` as double))",
          "cost_info": {
            "read_cost": "247.38",
            "eval_cost": "98.95",
            "prefix_cost": "1360.08",
            "data_read_per_join": "1M"
          },
          "used_columns": [
            "id",
            "key1",
            "key2",
            "key3",
            "key_part1",
            "key_part2",
            "key_part3",
            "common_field"
          ]
        }
      }
    ]
  }
}
1 row in set, 2 warnings (0.01 sec)

ステートメントの出力内容#を説明するためにコメントが続く形式を使用していますが、疑問があるかもしれません。「 」内のコストは奇妙に見えます。どのように計算されますか? まず表の「 」の部分を見てみましょう。EXPLAIN FORMAT=JSON
cost_infos1cost_info

"cost_info": {
    
    
    "read_cost": "914.80",
    "eval_cost": "98.95",
    "prefix_cost": "1013.75",
    "data_read_per_join": "1M"
}  

• read_costこれは次の 2 つの部分で構成されます。

  • IOコスト
  • rows × (1 - filter)レコード検出の CPU コスト

  ヒント: 行とフィルターは、前に紹介した実行プランの出力列です。JSON 形式の実行プランでは、行は rows_examined_per_scan に相当し、フィルターされた名前は変更されません。

• eval_costこのように計算されます

  レコードを検出するコストrows × filter。

• prefix_costこれはテーブルのみをクエリする場合のコストs1、つまり次のとおりです。

  read_cost + eval_cost

• data_read_per_joinこのクエリで読み取る必要があるデータの量を示します。

s2 テーブルの「cost_info」部分は次のようになります。

"cost_info": {
    
    
    "read_cost": "247.38",
    "eval_cost": "98.95",
    "prefix_cost": "1360.08",
    "data_read_per_join": "1M"
}

テーブルは駆動テーブルであるためs2、複数回読み取られる可能性があります。テーブルに複数回アクセスした後に累積された値read_costとここにあります。誰もが主に、接続クエリ全体の推定コストを表す内部の値に関心があります。つまり、テーブルの 1 回のクエリとテーブルの複数のクエリ後のコストの合計です。ます。eval_costs2
prefix_cost
s1s2

247.38 + 98.95 + 1013.75 = 1360.08

3. ツリー形式

TREE 形式はバージョン 8.0.16 以降に導入された新しい形式で、主にクエリに基づいてクエリを実行する方法各个部分之间的关系と、各部分的执行顺序

mysql> EXPLAIN FORMAT=tree SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a'\G
*************************** 1. row ***************************
EXPLAIN: -> Nested loop inner join  (cost=1360.08 rows=990)
    -> Filter: ((s1.common_field = 'a') and (s1.key1 is not null))  (cost=1013.75 rows=990)
        -> Table scan on s1  (cost=1013.75 rows=9895)
    -> Single-row index lookup on s2 using idx_key2 (key2=s1.key1), with index condition: (cast(s1.key1 as double) = cast(s2.key2 as double))  (cost=0.25 rows=1)

1 row in set, 1 warning (0.00 sec)

4. 視覚的な出力

ビジュアル出力。MySQL Workbench を通じて MySQL 実行プランを視覚的に表示できます。ワークベンチ の虫眼鏡アイコンをクリックすると
、視覚的なクエリ プランを生成できます。

上の図は、左から右の結合順序でテーブルを示しています。赤いボックスは を示し全表扫描、緑のボックスは使用を示します索引查找。テーブルごとに、
使用されているインデックスが表示されます。また、各テーブルのボックスの上には、各テーブル アクセスによって検出される行数と、
そのテーブルにアクセスするコストの推定値が表示されることに注意してください。

7.2 SHOW WARNINGSの使用

mysql> EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE
s2.common_field IS NOT NULL;

Explain を使用した直後に Explain を使用しますSHOW WARNINGS \G

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
  Level: Note
   Code: 1003
Message: /* select#1 */ select `atguigudb1`.`s1`.`key1` AS `key1`,`atguigudb1`.`s2`.`key1` AS `key1` from `atguigudb1`.`s1` join `atguigudb1`.`s2` where ((`atguigudb1`.`s1`.`key1` = `atguigudb1`.`s2`.`key1`) and (`atguigudb1`.`s2`.`common_field` is not null))
1 row in set (0.00 sec)

クエリ オプティマイザーによって実際に実行されたステートメントを確認できます。

突き出すと必ずしも実行できるとは限りません

SHOW WARNINGS表示された情報には、 、 、および の 3 つのフィールドがあるLevelことCodeがわかりますMessage。最も一般的な
情報は、コード 1003 の情報です。コード値が 1003 の場合、メッセージ フィールドに表示される情報は、查询优化器クエリ ステートメントを書き換えた後のステートメントと似ています。たとえば、上記のクエリはもともと左 (外部) 結合クエリでしたが、s2.common_field IS NOT NULL という条件があり、クエリ オプティマイザーによって左 (外部) 結合クエリが内部結合クエリに最適化されます。SHOW WARNINGSフィールドからMessage元の LEFT JOIN が JOIN (内部結合) になっていることがわかります。

8. オプティマイザーの実行計画を分析します: トレース

OPTIMIZER_TRACEMySQL 5.6で導入された追跡機能で、オプティマイザによるさまざまな決定（テーブルへのアクセス方法、各種コスト計算、各種変換など）を追跡し、追跡結果をテーブルに記録することができますINFORMATION_SCHEMA.OPTIMIZER_TRACE。

この機能はデフォルトではオフになっています。トレースを有効にし、形式を JSON に設定し、解析プロセス中にデフォルトのメモリが小さすぎるために完全な表示が行われないように、トレースが使用できる最大メモリ サイズを設定します。

SET optimizer_trace="enabled=on",end_markers_in_json=on;

set optimizer_trace_max_mem_size=1000000;

オンにすると、次のステートメントを分析できます。

• 選択する
• 入れる
• 交換する
• アップデート
• 消去
• 説明する
• セット
• 宣言する
• 場合
• もし
• 戻る
• 電話

テスト: 次の SQL ステートメントを実行します。

select * from student where id < 10;

最後に、information_schema.optimizer_trace をクエリして、MySQL が SQL を実行する方法を確認します。

select * from information_schema.optimizer_trace\G

mysql> select * from information_schema.optimizer_trace\G
*************************** 1. row ***************************
# //第1部分：查询语句
QUERY: select * from student where id < 10
//第2部分：QUERY字段对应语句的跟踪信息
TRACE: {
  "steps": [
    {
      "join_preparation": { /*预备工作*/
        "select#": 1,
        "steps": [
          {
            "expanded_query": "/* select#1 */ select `student`.`id` AS `id`,`student`.`stuno` AS `stuno`,`student`.`name` AS `name`,`student`.`age` AS `age`,`student`.`classId` AS `classId` from `student` where (`student`.`id` < 10)"
          }
        ] /* steps */
      } /* join_preparation */
    },
    {
      "join_optimization": {/*进行优化*/
        "select#": 1,
        "steps": [
          {
            "condition_processing": {/*条件处理*/
              "condition": "WHERE",
              "original_condition": "(`student`.`id` < 10)",
              "steps": [
                {
                  "transformation": "equality_propagation",
                  "resulting_condition": "(`student`.`id` < 10)"
                },
                {
                  "transformation": "constant_propagation",
                  "resulting_condition": "(`student`.`id` < 10)"
                },
                {
                  "transformation": "trivial_condition_removal",
                  "resulting_condition": "(`student`.`id` < 10)"
                }
              ] /* steps */
            } /* condition_processing */
          },
          {
            "substitute_generated_columns": {/*替换生成的列*/
            } /* substitute_generated_columns */
          },
          {
            "table_dependencies": [   /* 表的依赖关系*/
              {
                "table": "`student`",
                "row_may_be_null": false,
                "map_bit": 0,
                "depends_on_map_bits": [
                ] /* depends_on_map_bits */
              }
            ] /* table_dependencies */
          },
          {
            "ref_optimizer_key_uses": [ /* 使用键*/
            ] /* ref_optimizer_key_uses */
          },
          {
            "rows_estimation": [ /*行判断*/
              {
                "table": "`student`",
                "range_analysis": {
                  "table_scan": {
                    "rows": 3945207,
                    "cost": 404306
                  } /* table_scan */,/*表扫描*/
                  "potential_range_indexes": [
                    {
                      "index": "PRIMARY",
                      "usable": true,
                      "key_parts": [
                        "id"
                      ] /* key_parts */
                    }
                  ] /* potential_range_indexes */,
                  "setup_range_conditions": [ 
                  ] /* 设置条件范围 */,
                  "group_index_range": {
                    "chosen": false,
                    "cause": "not_group_by_or_distinct"
                  } /* group_index_range */,
                  "skip_scan_range": {
                    "potential_skip_scan_indexes": [
                      {
                        "index": "PRIMARY",
                        "usable": false,
                        "cause": "query_references_nonkey_column"
                      }
                    ] /* potential_skip_scan_indexes */
                  } /* skip_scan_range */,
                  "analyzing_range_alternatives": {/*分析范围选项*/
                    "range_scan_alternatives": [
                      {
                        "index": "PRIMARY",
                        "ranges": [
                          "id < 10"
                        ] /* ranges */,
                        "index_dives_for_eq_ranges": true,
                        "rowid_ordered": true,
                        "using_mrr": false,
                        "index_only": false,
                        "in_memory": 0.159895,
                        "rows": 9,
                        "cost": 1.79883,
                        "chosen": true
                      }
                    ] /* range_scan_alternatives */,
                    "analyzing_roworder_intersect": {
                      "usable": false,
                      "cause": "too_few_roworder_scans"
                    } /* analyzing_roworder_intersect */
                  } /* analyzing_range_alternatives */,
                  "chosen_range_access_summary": {/*选择范围访问摘要*/
                    "range_access_plan": {
                      "type": "range_scan",
                      "index": "PRIMARY",
                      "rows": 9,
                      "ranges": [
                        "id < 10"
                      ] /* ranges */
                    } /* range_access_plan */,
                    "rows_for_plan": 9,
                    "cost_for_plan": 1.79883,
                    "chosen": true
                  } /* chosen_range_access_summary */
                } /* range_analysis */
              }
            ] /* rows_estimation */
          },
          {
            "considered_execution_plans": [/*考虑执行计划*/
              {
                "plan_prefix": [
                ] /* plan_prefix */,
                "table": "`student`",
                "best_access_path": {/*最佳访问路径*/
                  "considered_access_paths": [
                    {
                      "rows_to_scan": 9,
                      "access_type": "range",
                      "range_details": {
                        "used_index": "PRIMARY"
                      } /* range_details */,
                      "resulting_rows": 9,
                      "cost": 2.69883,
                      "chosen": true
                    }
                  ] /* considered_access_paths */
                } /* best_access_path */,
                "condition_filtering_pct": 100, /*行过滤百分比*/
                "rows_for_plan": 9,
                "cost_for_plan": 2.69883,
                "chosen": true
              }
            ] /* considered_execution_plans */
          },
          {
            "attaching_conditions_to_tables": { /*将条件附加到表上*/
              "original_condition": "(`student`.`id` < 10)",
              "attached_conditions_computation": [
              ] /* attached_conditions_computation */,
              "attached_conditions_summary": [ /*附加条件概要*/
                {
                  "table": "`student`",
                  "attached": "(`student`.`id` < 10)"
                }
              ] /* attached_conditions_summary */
            } /* attaching_conditions_to_tables */
          },
          {
            "finalizing_table_conditions": [
              {
                "table": "`student`",
                "original_table_condition": "(`student`.`id` < 10)",
                "final_table_condition   ": "(`student`.`id` < 10)"
              }
            ] /* finalizing_table_conditions */
          },
          {
            "refine_plan": [ /*精简计划*/
              {
                "table": "`student`"
              }
            ] /* refine_plan */
          }
        ] /* steps */
      } /* join_optimization */
    },
    {
      "join_execution": {  /*执行*/
        "select#": 1,
        "steps": [
        ] /* steps */
      } /* join_execution */
    }
  ] /* steps */
}
/
/*第3部分：跟踪信息过长时，被截断的跟踪信息的字节数。*/
MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0 /*丢失的超出最大容量的字节*/
/*第4部分：执行跟踪语句的用户是否有查看对象的权限。当不具有权限时，该列信息为1且TRACE字段为空，一般在
调用带有SQL SECURITY DEFINER的视图或者是存储过程的情况下，会出现此问题。*/
INSUFFICIENT_PRIVILEGES: 0 /*缺失权限*/
1 row in set (0.01 sec)

9. MySQL 監視分析 view-sys スキーマ

9.1 システムスキーマビューの概要

1. ホスト関連: host_summary をはじめとして、主に IO 遅延情報がまとめられています。

2. Innodb 関連: innodb をはじめ、innodb のバッファ情報や innodb ロックを待っているトランザクションの情報をまとめています。

3. I/O 関連: io から始まり、I/O の待機と I/O の使用状況がまとめられています。

4. メモリ使用量: メモリから始まり、ホスト、スレッド、イベントなどの観点からメモリ使用量を表示します。

5. 接続とセッションの情報: プロセスリストとセッション関連のビューは、セッション関連の情報を要約します。

6. テーブル関連: schema_table で始まるビューには、テーブルの統計情報が表示されます。

7. インデックス情報: 冗長インデックスや未使用のインデックスを含む、インデックスの使用状況に関する統計。

8. ステートメント関連: ステートメントを始めとして、フルテーブルスキャンの実行、一時テーブルの使用、ソートなどのステートメント情報が含まれます。

9. ユーザー関連: ユーザーで始まるビューは、ユーザーが使用したファイル I/O および実行ステートメントの統計をカウントします。

10. 待機中のイベントに関する情報: wait から始まり、待機中のイベントの遅延を示します。

9.2 システムスキーマビューの使用シナリオ

インデックスステータス

#1. 查询冗余索引
select * from sys.schema_redundant_indexes;
#2. 查询未使用过的索引
select * from sys.schema_unused_indexes;
#3. 查询索引的使用情况
select index_name,rows_selected,rows_inserted,rows_updated,rows_deleted
from sys.schema_index_statistics where table_schema='dbname' ;

テーブル関連

# 1. 查询表的访问量
select table_schema,table_name,sum(io_read_requests+io_write_requests) as io from
sys.schema_table_statistics group by table_schema,table_name order by io desc;
# 2. 查询占用bufferpool较多的表
select object_schema,object_name,allocated,data
from sys.innodb_buffer_stats_by_table order by allocated limit 10;
# 3. 查看表的全表扫描情况
select * from sys.statements_with_full_table_scans where db='dbname';

発言関連

#1. 监控SQL执行的频率
select db,exec_count,query from sys.statement_analysis
order by exec_count desc;
#2. 监控使用了排序的SQL
select db,exec_count,first_seen,last_seen,query
from sys.statements_with_sorting limit 1;
#3. 监控使用了临时表或者磁盘临时表的SQL
select db,exec_count,tmp_tables,tmp_disk_tables,query
from sys.statement_analysis where tmp_tables>0 or tmp_disk_tables >0
order by (tmp_tables+tmp_disk_tables) desc;

IO関連

#1. 查看消耗磁盘IO的文件
select file,avg_read,avg_write,avg_read+avg_write as avg_io
from sys.io_global_by_file_by_bytes order by avg_read limit 10;

Innodb関連

#1. 行锁阻塞情况
select * from sys.innodb_lock_waits;

リスク警告:

sys ライブラリを介してクエリを実行すると、MySQL は関連情報を収集するために大量のリソースを消費し、深刻な場合にはビジネス リクエストがブロックされ、障害が発生する可能性があります。不要频繁実稼働環境では、監視、検査、およびその他のタスクを完了するために、sys または Performance_schema および information_schema をクエリすることをお勧めします。