一、性能分析 {#一性能分析}

1.1 数据库服务器的优化步骤 {#11-数据库服务器的优化步骤}

当我们遇到数据库调优问题的时候，该如何思考呢？这里把思考的流程整理成下面这张图。
整个流程划分成了观察(Show status)和行动(Action)两个部分。字母 S 的部分代表观察（会使用相应的分析工具），字母 A 代表的部分是行动（对应分析可以采取的行动）。
微信图片_20240615122420.jpg
小结：

1.2 查看系统性能参数 {#12--查看系统性能参数}

在MySQL中，可以使用SHOW STATUS 语句查询一些MySQL数据库服务器的性能参数、执行频率。
SHOW STATUS语句语法如下：

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

一些常用的性能参数如下：

Connections：连接MySQL服务器的次数。
Uptime：MySQL服务器的上线时间。
Slow_queries：慢查询的次数。
Innodb_rows_read：Select查询返回的行数
Innodb_rows_inserted：执行INSERT操作插入的行数
Innodb_rows_updated：执行UPDATE操作更新的行数
Innodb_rows_deleted：执行DELETE操作删除的行数
Com_select：查询操作的次数。
Com_insert：插入操作的次数。对于批量插入的 NSERT 操作，只累加一次。
Com_update：更新操作的次数。
Com_delete：删除操作的次数。

1.3 统计SQL的查询成本：last_query_cost {#13-统计sql的查询成本last_query_cost}

我们依然使用第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 ）
然后再看下查询优化器的成本，实际上我们只需要检索一个页即可：

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

如果我们想要查询 id 在 900001 到 9000100 之间的学生记录呢？

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 倍，但是查询的效率并没有明显的变化，实际上这两个 SQL 查询的时间基本上一样，就是因为采用了顺序读取的方式将页面一次性加载到缓冲池中，然后再进行查找。虽然页数量（last_query_cost）增加了不少，但是通过缓冲池的机制，并没有增加多少查询时间。

使用场景：它对于比较开销是非常有用的，特别是我们有好几种查询方式可选的时候。

1.4 定位执行慢的 SQL：慢查询日志 {#14-定位执行慢的-sql慢查询日志}

1.4.1 开启慢查询日志参数 {#141-开启慢查询日志参数}

开启slow_query_log

mysql > set global slow_query_log='ON';

然后我们再来查看下慢查询日志是否开启，以及慢查询日志文件的位置：

你能看到这时慢查询分析已经开启，同时文件保存在 /var/lib/mysql/atguigu02-slow.log 文件中。
2. 修改long_query_time阈值
接下来我们来看下慢查询的时间阈值设置，使用如下命令：

mysql > show variables like '%long_query_time%';

这里如果我们想把时间缩短，比如设置为 1 秒，可以这样设置：

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

1.4.2 查看慢查询数目 {#142-查看慢查询数目}

查询当前系统中有多少条慢查询记录

SHOW GLOBAL STATUS LIKE '%Slow_queries%';

1.4.3 案例演示 {#143-案例演示}

步骤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);

1.4.4 测试及分析 {#144-测试及分析}

测试

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';

1.4.5 慢查询日志分析工具：mysqldumpslow {#145-慢查询日志分析工具mysqldumpslow}

在生产环境中，如果要手工分析日志，查找、分析SQL，显然是个体力活，MySQL提供了日志分析工具mysqldumpslow。
查看mysqldumpslow的帮助信息

mysqldumpslow --help

mysqldumpslow 命令的具体参数如下：

-a: 不将数字抽象成N，字符串抽象成S
-s: 是表示按照何种方式排序：
- c: 访问次数
- l: 锁定时间
- r: 返回记录
- t: 查询时间
- al:平均锁定时间
- ar:平均返回记录数
- at:平均查询时间（默认方式）
- ac:平均查询次数
-t: 即为返回前面多少条的数据；
-g: 后边搭配一个正则匹配模式，大小写不敏感的；
举例：我们想要按照查询时间排序，查看前五条 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

1.4.6 关闭慢查询日志 {#146-关闭慢查询日志}

MySQL服务器停止慢查询日志功能有两种方法：
方式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%';

1. 4.7 删除慢查询日志 {#1-47-删除慢查询日志}

1.5. 查看 SQL 执行成本：SHOW PROFILE {#15-查看-sql-执行成本show-profile}

mysql > show variables like 'profiling';

通过设置 profiling='ON' 来开启 show profile：

mysql > set profiling = 'ON';

然后执行相关的查询语句。接着看下当前会话都有哪些 profiles，使用下面这条命令：

mysql > show profiles;

你能看到当前会话一共有 2 个查询。如果我们想要查看最近一次查询的开销，可以使用：

mysql > show profile;

mysql> show profile cpu,block io for query 2;

show profile的常用查询参数：
① ALL：显示所有的开销信息。
② BLOCK IO：显示块IO开销。
③ CONTEXT SWITCHES：上下文切换开销。
④ CPU：显示CPU开销信息。
⑤ IPC：显示发送和接收开销信息。
⑥ MEMORY：显示内存开销信息。
⑦ PAGE FAULTS：显示页面错误开销信息。
⑧ SOURCE：显示和Source_function，Source_file，Source_line相关的开销信息。
⑨ SWAPS：显示交换次数开销信息。****

1.6 分析查询语句：EXPLAIN {#16-分析查询语句explain}

1.6.1 概述 {#161-概述}

官网介绍
官网
 官网

版本情况

MySQL 5.6.3以前只能EXPLAIN SELECT ；MYSQL 5.6.3以后就可以EXPLAIN SELECT，UPDATE，DELETE
在5.7以前的版本中，想要显示partitions 需要使用explain partitions 命令；想要显示filtered 需要使用explain extended 命令。在5.7版本后，默认explain直接显示partitions和filtered中的信息。

1.6.2 基本语法 {#162-基本语法}

EXPLAIN 或 DESCRIBE语句的语法形式如下：

EXPLAIN SELECT select_options
或者
DESCRIBE SELECT select_options

如果我们想看看某个查询的执行计划的话，可以在具体的查询语句前边加一个EXPLAIN，就像这样：

mysql> EXPLAIN SELECT 1;

EXPLAIN 语句输出的各个列的作用如下：

1.6.3 数据准备 {#163-数据准备}

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表数据的添加：加入1万条记录：

CALL insert_s1(10001,10000);

s2表数据的添加：加入1万条记录：

CALL insert_s2(10001,10000);

1.6.4 EXPLAIN各列作用 {#164-explain各列作用}

为了让大家有比较好的体验，我们调整了下EXPLAIN 输出列的顺序。

table
不论我们的查询语句有多复杂，里边儿包含了多少个表，到最后也是需要对每个表进行单表访问的，所以MySQL规定EXPLAIN语句输出的每条记录都对应着某个单表的访问方法，该条记录的table列代表着该表的表名（有时不是真实的表名字，可能是简称）。
id
我们写的查询语句一般都以SELECT 关键字开头，比较简单的查询语句里只有一个SELECT 关键字，比如下边这个查询语句：

SELECT * FROM s1 WHERE key1 = 'a';

稍微复杂一点的连接查询中也只有一个SELECT 关键字，比如：

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

一条查询语句中涉及一个表，则只有一条记录

mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2;

一条查询语句中涉及两张表，则有两条记录，对于链接查询，一个SELECT关键字后面的FROM子句可以跟随多个表，所以每个表都会对应一条记录，但是id都会是SELECT关键字的id。

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

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

可以看到，上述连接查询中参与连接的s1和s2表分别对应一条记录，但是这两条记录对应的id值都是1。这里需要大家记住的是，在连接查询的执行计划中，每个表都会对应一条记录，这些记录的id列的值是相同的 ，出现在前边的表表示驱动表，出现在后边的表表示被驱动表。所以从上边的EXPLAIN输出中我们可以看出，查询优化器准备让s1表作为驱动表，让s2表作为被驱动表来执行查询，
对于包含子査询的查询语句来说，就可能涉及多个SELECT 关键字，所以在包含子查询的查询语句的执行计划中，每个 SELECT 关键字都会对应一个唯一的d值 ，比如这样:

mysql> EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

查询中包含union与语句的情况，查询语句中每出现一个SELECT关键字，MYSQL就会为它分配一个唯一的ID值。这个id值就是EXPLAIN语句的第一列
可以看到，虽然我们的查询语句是一个子查询，但是执行计划中s1和s2表对应的记录的 id 值全部是1，这就表明了查询优化器将子查询转换为了连接查询 。

这个语句的执行计划的第三条记录是什么?为何id值是NULL，而且table列也很奇怪?UNION!它会把多个查询的结果集合并起来并对结果集中的记录进行去重，怎么去重呢?MySQL使用的是内部的 临时表 。正如上边的查询计划中所示，UNION子句是为了把id为1的査询和id为2的查询的结果集合并起来并去重，所以在内部创建了一个名为<union1，2>的临时表(就是执行计划第三条记录的table列的名称)，id为NULL表明这个临时表是为了合并两个查询的结果集而创建的。

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

跟UNION对比起来， UNION ALL就不需要为最终的结果集进行去重，它只是单纯的把多个查询的结果集中的记录合并成一个并返回给用户，所以也就不需要使用临时表。所以在包含UNION ALL 子句的查询的执行计划中，就没有那个id为NULL的记录，如下所示

小结:

id如果相同，可以认为是一组，从上往下顺序执行
所有组中，id值越大，优先级越高，越先执行
关注点：id号每个号码，表示一趟独立的查询, 一个sql的查询趟数越少越好

select_type
一条大的查询语句里边可以包含若干个SELECT关键字，每个SELECT关键字代表着一个小的查询语句，而每个SELECT关键字的FROM子句中都可以包含若干张表(这些表用来做连接查询)，每一张表都对应着执行计划输出中的一条记录，对于在同一个SELECT关键字中的表来说，它们的id值是相同的。
MySQL为每一个SELECT关键字代表的小査询都定义了一个称之为select_type 的属性，意思是我们只要知道了某个小査询的 select_type属性，就知道了这个 小査询在整个大査询中扮演了一个什么角色，我们看一下select_type都能取哪些值，请看官方文档:

具体分析如下：

mysql> EXPLAIN SELECT * FROM s1;

当然，连接查询也算是SIMPLE 类型，比如：

mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2;

查询语句中不包含UNION或者子査询的査询都算作是SIMPLE类型

PRIMARY
对于包含UNION或者UNION_ALL或者子查询的大查询来说，它是由几个小查询组成的，其中最左边的
查询的select type值就是PRIMARY

mysql> EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

UNION
对于包含UNION或者UNION ALL的大查询来说，它是由几个小查询组成的，其中除了最左边的那个小查询
以外，其余的小查询的select type值就是UNION
UNION RESULT
MySQL选择使用临时表来完成UNION查询的去重工作，针对该临时表的査询的select type就是UNION RESULT
SUBQUERY
如果包含子查询的査询语句不能够转为对应的semi-ioin的形式，并且该子查询是不相关子查询。
该子查询的第一个SELECT关键字代表的那个査询的select type就是SUBQUERY

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

DEPENDENT SUBQUERY
如果包含子查询的査询语句不能够转为对应的semi-join的形式，并且该子查询是相关子查询,则该子查询的第一个SELECT关键字代表的那个査询的select type就是DEPENDENT SUBQUERY

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

DEPENDENT UNION
在包含UNION或者UNION ALL的大查询中，如果各个小查询都依赖于外层查询的话，那除了最左边的那个小查询之外，其余的小査询的select type的值就是DEPENDENT UNION。(in关键字优化器会改造为相关子查询)

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

DERIVED
对于包含派生表的查询，该派生表对应的子査询的select type就是DERIVED

mysql> EXPLAIN SELECT * FROM (SELECT key1, count(*) as c FROM s1 GROUP BY key1) AS derived_s1 where c > 1;

MATERIALIZED
当查询优化器在执行包含子查询的语句时，选择将子查询物化之后与外层查询进行连接查询时，
该子查询对应的select type属性就是MATERIALIZED

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2);

UNCACHEABLE SUBQUERY
UNCACHEABLE UNION

partitions (可略)

如果想详细了解，可以如下方式测试。创建分区表：

-- 创建分区表，
-- 按照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分区）的记录，查看执行计划，partitions是p1，符合我们的分区规则

type ☆
执行计划的一条记录就代表着MySQL对某个表的 执行査询时的访问方法，又称"访问类型"，其中的type 列就表明了这个访问方法是啥，是较为重要的一个指标。比如，看到type列的值是ref，表明MySQL即将使用ref访问方法来执行对s1表的查询。
完整的访问方法如下： system ， const ， eq_ref ， ref ， fulltext ， ref_or_null ，index_merge ， unique_subquery ， index_subquery ， range ， index ， ALL 。
我们详细解释一下：

system
当表中只有一条记录并且该表使用的存储引擎的统计数据是精确的，比如MyISAM、Memory，那么对该表的访问方法就是 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;

const
当我们根据主键或者唯一二级索引列与常数进行等值匹配时，对单表的访问方法就是const

mysql> EXPLAIN SELECT * FROM s1 WHERE id = 10005;

eq_ref
在连接查询时，如果被驱动表是通过主键或者唯一二级索引列等值匹配的方式进行访问的(如果该主键或者唯一二级索引是联合索引的话，所有的索引列都必须进行等值比较)，则对该被驱动表的访问方法就是eq ref

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

从执行计划的结果中可以看出，MySQL打算将s2作为驱动表，s1作为被驱动表，重点关注s1的访问
方法是eq_ref ，表明在访问s1表的时候可以通过主键的等值匹配来进行访问。

ref
当通过普通的二级索引列与常量进行等值匹配时来查询某个表，那么对该表的访问方法就可能是`ref

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

fulltext
全文索引
ref_or_null
当对普通二级索引进行等值匹配查询，该索引列的值也可以是NULL值时，那么对该表的访问方法就可能是ref_or_null

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

index_merge
单表访问方法时在某些场景下可以使用Intersection'、'union'sort-union这三种索引合并的方式来执行查询

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

从执行计划的type列的值是index_merge就可以看出，MySQL 打算使用索引合并的方式来执行对s1表的查询。

unique_subquery
unique_subquery是针对在一些包含IN子査询的査询语句中，如果查询优化器决定将IN子查询转换为EXISTS子查询，而且子査询可以使用到主键进行等值匹配的话，那么该子查询执行计划的type列的值就是unique subquery

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

index_subquery

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

range
如果使用索引获取某些范围区间的记录，那么就可能使用到range访问方法

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN ('a', 'b', 'c');

或者：

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'a' AND key1 < 'b';

index
当我们可以使用索引覆盖，但需要扫描全部的索引记录时，该表的访问方法就是index

mysql> EXPLAIN SELECT key_part2 FROM s1 WHERE key_part3 = 'a';

ALL
全表扫描

mysql> EXPLAIN SELECT * FROM s1;

一般来说，这些访问方法中除了 A11这个访问方法外，其余的访问方法都能用到索引，除了 index_merge 访问方法外，其余的访问方法都最多只能用到一个索引。
小结：
结果值从最好到最坏依次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL 其中比较重要的几个提取出来（见上图中的蓝色）。SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，最好是 consts级别。（阿里巴巴开发手册要求）

possible_keys和key
在EXPLAIN语句输出的执行计划中，possible_keys列表示在某个查询语句中，对某个表执行单表查询时可能用到的索引有哪些。一般查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。key列表示实际用到的索引有哪些，如果为NULL，则没有使用索引。比方说下边这个查询:

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

上述执行计划的 possible_keys 列的值是 idx_key1,idx_key3 ，表示该査询可能使用到 idx_key1, idx_key3 两个索引，然后 key 列的值是 idx_key3 ，表示经过査询优化器计算使用不同索引的成本后，最后决定使用idx_key3比较划算。
7. key_len ☆
实际使用到的索引长度(即:字节数)
帮你检查是否充分的利用上了索引，值越大越好,主要针对联合索引，有一定的参考意义。

mysql> EXPLAIN SELECT * FROM s1 WHERE id = 10005;

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

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

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

mysql> EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b';

练习：
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)

ref
当使用索引列等值查询时，与索引列进行等值匹配的对象信息。比如只是一个常数或者是某个列。

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

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

mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s2.key1 = UPPER(s1.key1);

9. rows ☆
预估的需要读取的记录条数，值越小越好

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z';

10. filtered
某个表经过搜索条件过滤后剩余的记录条数的百分比，如果使用的是索引执行的单表扫描，那么计算时需要估计出满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。百分比越高越好

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

对于单表查询来说，这个filtered列的值没什么意义，我们、更关注在连接查询中驱动表对应的执行计划记录的filtered值，它决定了被驱动表要执行的次数(即:rows * filtered)

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

从执行计划中可以看出来，查询优化器打算把s1当作驱动表，s2 当作被驱动表。我们可以看到驱动表 s1 表的执行计划的rows列为 9688， filtered列为 10.88，这意味着驱动表s1的扇出值就是9688 x 10.88%=968.8，这说明还要对被驱动表执行大约 968次查询。

11. Extra ☆
顾名思义，Extra列是用来说明一些额外信息的，包含不适合在其他列中显示但十分重要的额外信息。我们可以通过这些额外信息来 更准确的理解MSQL到底将如何执行给定的査询语句。MySQL提供的额外信息有好几十个，我们就不一个一个介绍了，所以我们只挑比较重要的额外信息介绍给大家。

No tables used
当查询语句的没有 FROM 子句时将会提示该额外信息，比如:

mysql> EXPLAIN SELECT 1;

Impossible WHERE
查询语句的WHERE子句永远为FALSE时将会提示该额外信息

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

Using where
当我们使用全表扫描来执行对某个表的查询，并且该语句的WERE、子句中有针对该表的搜索条件时，在Extra列中会提示上述额外信息。

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

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

No matching min/max row
当查询列表处有MIN或者MAX聚合函数，但是并没有符合WHERE子句中的搜索条件的记录时，将会提示该额外信息。

mysql> EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'abcdefg';

Using index
当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用覆盖索引的情况下，在Extra列将会提示该额外信息。比方说下边这个查询中只需要用到idx key1而不需要回表操作:

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

Using index condition
有些搜索条件中虽然出现了索引列，但却不能使用到索引看课件理解索引条件下推

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

其中的 key1>'z'可以使用到索引，但是key1 LIKE'%a'却无法使用到索引，在以前版本的MySQL中，是按照下边步骤来执行这个查询的:

先根据 key1 >'z'这个条件，从二级索引idx_key1 中获取到对应的二级索引记录。
根据上一步骤得到的二级索引记录中的主键值进行回表，找到完整的用户记录再检测该记录是否符合key1 LIKE'%a'这个条件，将符合条件的记录加入到最后的结果集。
但是虽然key1 LIKE'%a'不能组成范围区间参与range 访问方法的执行，但这个条件毕竟只涉及到了key1列，所以MySQL把上边的步骤改进了一下:
先根据 key1 >'z'这个条件，定位到二级索引 idx_key1 中对应的二级索引记录。
对于指定的二级索引记录，先不着急回表，而是先检测一下该记录是否满足 key1 LIKE'%a'这个条件如果这个条件不满足，则该二级索引记录压根儿就没必要回表。
对于满足 key1 LIKE '%a'这个条件的二级索引记录执行回表操作。
我们说回表操作其实是一个 随机I0，比较耗时，所以上述修改虽然只改进了一点点，但是可以省去好多回表操作的成本。MySQL把他们的这个改进称之为索引条件下推(英文名:Index condition Pushdown)如果在查询语句的执行过程中将要使用索引条件下推这个特性，在Extra列中将会显示Using indexcondition，比如这样:

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

Using join buffer (Block Nested Loop)
在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为其分配一块名叫join buffer的内存块来加快査询速度，也就是我们所讲的基于块的嵌套循环算法

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

可以在对s2表的执行计划的Extra列显示了两个提示：

Using join buffer(Block Nested Loop):这是因为对表s2的访问不能有效利用索引，只好退而求其次，使用join buffer来减少对s2表的访问次数，从而提高性能。
Using where:可以看到查询语句中有一个s1.common_field=s2.common_field条件，因为s1是驱动表，s2是被驱动表，所以在访问s2表时，s1.common_field的值已经确定下来了，所以实际上查询s2表的条件就是 s2.common_field =一个常数，所以提示了Using where 额外信息。

Not exists
当我们使用左(外)连接时，如果WHERE子句中包含要求被驱动表的某个列等于NULL值的搜索条件，而且那个列又是不允许存储NULL值的，那么在该表的执行计划的Extra列就会提示Not exists额外信息。

mysql> EXPLAIN SELECT * FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.id IS NULL;

上述查询中s1表是驱动表，s2表是被驱动表，s2.id列是不允许存储 NULL值的，而WHERE子句中又包含s2.id IS NULL的搜索条件，这意味着必定是驱动表的记录在被驱动表中找不到匹配 ON 子句条件的记录才会把该驱动表的记录加入到最终的结果集，所以对于某条驱动表中的记录来说，如果能在被驱动表中找到1条符合 ON 子句条件的记录，那么该驱动表的记录就不会被加入到最终的结果集，也就是说我们没有必要到被驱动表中找到全部符合ON子句条件的记录，这样可以稍微节省一点性能。

小贴士: 右(外)连接可以被转换为左(外)连接，所以就不提右(外)连接的情况了。

Using intersect(...) 、Using union(...) 和Using sort_union(...)
如果执行计划的Extra列出现了using intersect(...)提示，说明准备使用Intersect索引合并的方式执行查询，括号中的...表示需要进行索引合并的索引名称;
如果出现了using union(...)提示，说明准备使用union索引合并的方式执行查询;出现了Using sort union(...)提示，说明准备使用sort-Union索引合并的方式执行査询。

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

其中 Extra列就显示了Using union(idx_key3,idx_key1)，表明MySQL 即将使用 idx_key3 和idx_key1 这两个索引进行 Union 索引合并的方式执行查询。

Zero limit
当我们的LIMIT子句的参数为0时，表示压根儿不打算从表中读出任何记录，将会提示该额外信息

mysql> EXPLAIN SELECT * FROM s1 LIMIT 0;

Using filesort
有一些情况下对结果集中的记录进行排序是可以使用到索引的。
比如:

mysql> EXPLAIN SELECT * FROM s1 ORDER BY key1 LIMIT 10;

这个查询语句可以利用 idx_key1索引直接取出 key1列的10条记录，然后再进行回表操作就好了。但是很多情况下排序操作无法使用到索引，只能在内存中(记录较少的时候)或者磁盘中(记录较多的时候)进行排序，MySQL把这种在内存中或者磁盘上进行排序的方式统称为文件排序(英文名: filesort)。如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的Extra列中显示Using filesort 提示，比如这样:

mysql> EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10;

需要注意的是，如果查询中需要使用filesort的方式进行排序的记录非常多，那么这个过程是很耗费性能的，我们最好想办法将使用文件排序的执行方式改为用索引进行排序

Using temporary
在许多查询的执行过程中，MySQL可能会借助临时表来完成一些功能，比如去重、排序之类的，比如我们在执行许多包含DISTINCT'、'GROUP BY、UNION等子句的查询过程中，如果不能有效利用索引来完成查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。如果查询中使用到了内部的临时表，在执行
计划的Extra列将会显示Using temporary提示

mysql> EXPLAIN SELECT DISTINCT common_field FROM s1;

再比如：

mysql> EXPLAIN SELECT common_field, COUNT(*) AS amount FROM s1 GROUP BY common_field;

执行计划中出现Using temporary并不是一个好的征兆，因为建立与维护临时表要付出很大成本的，所以
我们最好能使用索引来替代掉使用临时表比如:扫描指定的索引idx_key1即可

mysql> EXPLAIN SELECT key1, COUNT(*) AS amount FROM s1 GROUP BY key1;

从Extra的Using index的提示里我们可以看出，上述查询只需要扫描idx_key1 索引就可以搞定了，不再需要临时表了。

其它
其它特殊情况这里省略。

小结

EXPLAIN不考虑各种Cache
EXPLAIN不能显示MySQL在执行查询时所作的优化工作
EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况部分统计信息是估算的，并非精确值

1.7 EXPLAIN的进一步使用 {#17-explain的进一步使用}

1.7.1 EXPLAIN四种输出格式 {#171-explain四种输出格式}

这里谈谈EXPLAIN的输出格式。EXPLAIN可以输出四种格式：传统格式， JSON格式，TREE格式以及可视化输出。用户可以根据需要选择适用于自己的格式。

传统格式
传统格式简单明了，输出是一个表格形式，概要说明查询计划。

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

2. JSON格式
第1种格式中介绍的 EXPLAIN语句输出中缺少了一个衡量执行计划好坏的重要属性 -- 成本。而JSON格式是四种格式里面输出 信息最详尽 的格式，里面包含了执行的成本信息。

JSON格式：在EXPLAIN单词和真正的查询语句中间加上FORMAT=JSON 。

EXPLAIN FORMAT=JSON SELECT ....

EXPLAIN 的Column与 JSON 的对应关系:(来源于MySQL 5.7文档)

我们使用# 后边跟随注释的形式为大家解释了EXPLAIN FORMAT=JSON 语句的输出内容，但是大家可能有疑问"cost_info" 里边的成本看着怪怪的，它们是怎么计算出来的？先看s1 表的"cost_info" 部
分：

"cost_info": {
"read_cost": "1840.84",
"eval_cost": "193.76",
"prefix_cost": "2034.60",
"data_read_per_join": "1M"
}

read_cost 是由下边这两部分组成的：
- IO 成本
- 检测rows × (1 - filter) 条记录的CPU 成本

小贴士： rows和filter都是我们前边介绍执行计划的输出列，在JSON格式的执行计划中，row相当于rows_examined_per_scan，filtered名称不变。

eval_cost 是这样计算的：
检测 rows × filter 条记录的成本。
prefix_cost 就是单独查询s1 表的成本，也就是：read_cost + eval_cost
data_read_per_join 表示在此次查询中需要读取的数据量。
对于s2 表的"cost_info" 部分是这样的：

"cost_info": {
"read_cost": "968.80",
"eval_cost": "193.76",
"prefix_cost": "3197.16",
"data_read_per_join": "1M"
}

由于s2 表是被驱动表，所以可能被读取多次，这里的read_cost 和eval_cost 是访问多次s2 表后累
加起来的值，大家主要关注里边儿的prefix_cost 的值代表的是整个连接查询预计的成本，也就是单
次查询s1 表和多次查询s2 表后的成本的和，也就是：

968.80 + 193.76 + 2034.60 = 3197.16

TREE格式
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)

可视化输出
可视化输出，可以通过MySQL Workbench可视化查看MySQL的执行计划。通过点击Workbench的放大镜图标，即可生成可视化的查询计划。
上图按从左到右的连接顺序显示表。红色框表示全表扫描，而绿色框表示使用索引查找。对于每个表，
显示使用的索引。还要注意的是，每个表格的框上方是每个表访问所发现的行数的估计值以及访问该表
的成本。

1.7.2 SHOW WARNINGS的使用 {#172-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;

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

大家可以看到 SHOW WARNINGS 展示出来的信息有三个字段，分别是Level、Code、Message。我们最常见的就是code为1003的信息，当code值为1003时，Message 字段展示的信息类似于查询优化器将我们的查询语句重写后的语句。比如我们上边的查询本来是一个左(外)连接查询，但是有一个s2.common_field IS NOT NULL的条件，这就会导致查询优化器把左(外)连接查询优化为内连接查询，从SHOW WARNINGS的Message字段也可以

1.8. 分析优化器执行计划：trace {#18-分析优化器执行计划trace}

SET optimizer_trace="enabled=on",end_markers_in_json=on;
set optimizer_trace_max_mem_size=1000000;

开启后，可分析如下语句：

SELECT
INSERT
REPLACE
UPDATE
DELETE
EXPLAIN
SET
DECLARE
CASE
IF
RETURN
CALL

测试：执行如下SQL语句

select * from student where id < 10;

最后，查询 information_schema.optimizer_trace 就可以知道MySQL是如何执行SQL的：

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": 3973767,
"cost": 408558
} /* table_scan */, //扫描表
"potential_range_indexes": [ //潜在的范围索引
{
"index": "PRIMARY",
"usable": true,
"key_parts": [
"id"
] /* key_parts */
}
] /* potential_range_indexes */,
"setup_range_conditions": [ //设置范围条件
] /* 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,
"rows": 9,
"cost": 1.91986,
"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.91986,
"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.81986,
"chosen": true
}
] /* considered_access_paths */
} /* best_access_path */,
"condition_filtering_pct": 100, //行过滤百分比
"rows_for_plan": 9,
"cost_for_plan": 2.81986,
"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.00 sec)

1.9. MySQL监控分析视图-sys schema {#19-mysql监控分析视图-sys-schema}

1.9.1 Sys schema视图摘要 {#191-sys-schema视图摘要}

主机相关：以host_summary开头，主要汇总了IO延迟的信息。
Innodb相关：以innodb开头，汇总了innodb buffer信息和事务等待innodb锁的信息。
I/o相关：以io开头，汇总了等待I/O、I/O使用量情况。
内存使用情况：以memory开头，从主机、线程、事件等角度展示内存的使用情况
连接与会话信息：processlist和session相关视图，总结了会话相关信息。
表相关：以schema_table开头的视图，展示了表的统计信息。
索引信息：统计了索引的使用情况，包含冗余索引和未使用的索引情况。
语句相关：以statement开头，包含执行全表扫描、使用临时表、排序等的语句信息。
用户相关：以user开头的视图，统计了用户使用的文件I/O、执行语句统计信息。
等待事件相关信息：以wait开头，展示等待事件的延迟情况。

1.9.2 Sys schema视图使用场景 {#192-sys-schema视图使用场景}

索引情况

#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;

51工具盒子

【MySQL】MySQL 入门必知必会其高级六：性能分析及相关工具