性能分析工具的使用（超详细）

数据库服务器的优化步骤

整个流程划分成了观察（Show status）和行动（Action）两个部分。字母 S 的部分代表观察（会使用相应的分析工具），字母 A 代表的部分是行动（对应分析可以采取的行动）。

首先在S1部分，我们需要观察服务器的状态是否存在周期性的波动。如果存在周期性波动，有可能是周期性节点的原因，比如双十一、促销活动等。这样的话，我们可以通过A1这一步骤解决，也就是加缓存，或者更改缓存失效策略
如果缓存策略没有解决，或者不是周期性波动的原因，我们就需要进一步分析查询延迟和卡顿的原因。接下来进入 S2这一-步，我们需要开启慢查询。慢查询可以帮我们定位执行慢的SQL语句。我们可以通过设置long_query_time参数定义“慢”的阈值，如果SQL执行时间超过了long_query_time，则会认为是慢查询。当收集上来这些慢查询之后，我们就可以通过分析工具对慢查询日志进行分析
在S3这一步骤中，我们就知道了执行慢的SQL，这样就可以针对性地用**EXPLAIN**查看对应SQL语句的执行计划，或者使用**show profile**查看SQL中每一个步骤的时间成本。这样我们就可以了解SQL查询慢是因为执行时间长，还是等待时间长。
如果是SQL等待时间长，我们进入A2步骤。在这一步骤中，我们可以调优服务器的参数，比如适当增加数据库缓冲池等。如果是SQL执行时间长，就进入A3步骤，这一步中我们需要考虑是索引设计的问题?还是查询关联的数据表过多?还是因为数据表的字段设计问题导致了这一现象。然后在这些维度上进行对应的调整。
如果A2和A3都不能解决问题，我们需要考虑数据库自身的SQL查询性能是否已经达到了瓶颈，如果确认没有达到性能瓶颈，就需要重新检查，重复以上的步骤。如果已经达到了性能瓶颈，进入A4阶段，需要考虑增加服务器，采用读写分离的架构，或者考虑对数据库进行分库分表，比如垂直分库、垂直分表和水平分表等

查看系统性能参数

可以使用show status语句查询mysql数据库服务器的性能参数，执行频率。
语法：
:::tips
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：插入操作的次数。对于批量插入的 INSERT 操作，只累加一次。
Com_update：更新操作的次数。
Com_delete：删除操作的次数。

统计SQL的查询成本：last_query_cost

一条SQL查询语句在执行前需要确定查询执行计划，如果存在多种执行计划的话，MySQL会计算每个执行计划所需要的成本，从中选择成本最小的一个作为最终执行的执行计划。
如果我们想要查看某条SQL语句的查询成本，可以在执行完这条SQL语句之后，通过查看当前会话中的 last_query_cost变量值来得到当前查询的成本。它通常也是我们评价一个查询的执行效率的一个常用指标。这个查询成本对应的是SQL语句所需要读取的页的数量。
以student_info表为例，里面有100万条数据。

如果我们想要查询 id=900001 的记录，然后看下查询成本，我们可以直接在聚簇索引上进行查找

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

运行结果（1条记录，运行时间为 0.00s）
然后再看下查询优化器的成本，实际上我们只需要检索一个页即可：

查询 id 在 900001 到 9000100 之间的学生记录呢？

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

运行结果（100 条记录，运行时间为 0.00s ）
然后再看下查询优化器的成本，这时我们大概需要进行 20 个页的查询。

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

SQL查询是一个动态的过程，从页加载的角度来看，我们可以得到以下两点结论:

位置决定效率。如果页就在数据库缓冲池中，那么效率是最高的，否则还需要从磁盘中进行读取，当然针对单个页的读取来说，如果页存在于内存中，会比在磁盘中读取效率高很多。
批量决定效率。如果我们从磁盘中对单一页进行随机读，那么效率是很低的(差不多10ms)，而采用顺序读取的方式，批量对页进行读取，平均一页的读取效率就会提升很多，甚至要快于单个页面在内存中的随机读取。

所以说，遇到/O并不用担心，方法找对了，效率还是很高的。我们首先要考虑数据存放的位置，如果是经常使用的数据就要尽量放到缓冲池中，其次我们可以充分利用磁盘的吞吐能力，一次性批量读取数据，这样单个页的读取效率也就得到了提升。

定位查询慢的SQL：慢查询日志

MySQL的慢查询日志，用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10秒以上(不含10秒)的语句，认为是超出了我们的最大忍耐时间值。
它的主要作用是，帮助我们发现那些执行时间特别长的SQL查询，并且有针对性地进行优化，从而提高系统的整体效率。当我们的数据库服务器发生阻塞、运行变慢的时候，检查一下慢查询日志，找到那些慢查询，对解决问题很有帮助。
默认情况下，MySQL数据库没有开启慢查询日志，需要我们手动来设置这个参数。如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响

开启慢查询日志

开启slow_query_log

查看慢查询日志是否开启，以及慢查询日志文件的位置

show variables like '%slow_query_log%';

开启慢查询日志

set global slow_query_log = 'on';

修改long_query_time的阈值

查看慢查询的时间阈值

show variables like '%long_query_time%';

修改时间阈值

# global对当前session的long_query_time失效，对新连接的客服端有效
set global long_query_time = 1;
show global variables like '%long_query_time%';
# 修改当前session
set long_query_time = 1;
show variables like '%long_query_time%';

在配置文件中修改

修改my.cnf文件，[mysqld]下增加或修改参数long_query_time、slow_query_log和slow_query_log_file后，然后重启MySQL服务器。

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

查看慢查询数目

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

 show global status like '%slow_queries%';

案例演示

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

测试及分析

测试

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秒。已经达到了秒的数量级，说明目前查询效率是比较低的，下面的小节我们分析一下原因

分析

show status like 'slow_queries';

除了上述变量，控制慢查询日志的还有一个系统变量: min_examined_row_limit。这个变量的意思是，查询扫描过的最少记录数。这个变量和查询执行时间，共同组成了判别一个查询是否是慢查询的条件。如果查询扫描过的记录数大于等于这个变量的值，并且查询执行时间超过long_query_time的值，那么，这个查询就被记录到慢查询日志中; 反之，则不被记录到慢查询日志中
:::tips
mysql> show variables like ‘min%’;
±-----------------------±------+
| Variable_name | Value |
±-----------------------±------+
| min_examined_row_limit | 0 |
±-----------------------±------+
1 row in set (0.00 sec)
:::

慢查询日志分析工具：mysqldumpslow

在生产环境中，如果要手工分析日志，查找、分析SQL，显然是个体力活，MySQL提供了日志分析工具mysqldumpslow
查看mysqldumpslow的帮助信息
:::tips
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

工作常用：

#得到返回记录集最多的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

关闭慢查询日志

除了调优需要开，正常还是不要开了

永久性关闭

[mysqld]
slow_query_log=off;
# 或者在配置文件中注释掉
[mysqld]
#slow_query_log =OFF

临时性关闭

SET GLOBAL slow_query_log=off;

删除慢查询日志

通过show variables like '%slow_query_log%'查看mysql的数据目录，在该目录下手动删除慢查询的日志文件即可。再使用mysqladmin flush-logs重新生成查询日志文件。

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

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

慢查询日志都是使用mysqladmin flush-logs命令来删除重建的。使用时-定要注意，一旦执行了这个命令，慢查询日志都只存在新的日志文件中，如果需要旧的查询日志，就必须事先备份。

查看SQL执行成本：show profile

Show Profile是MySQL提供的可以用来分析当前会话中SQL都做了什么、执行的资源消耗情况的工具，可用于sql调优的测量。默认情况下处于关闭状态，并保存最近15次的运行结果。
在会话级别开启该功能

SHOW VARIABLES LIKE 'profiling';

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

SET profiling = 'on';

然后执行相关的查询语句。接着看下当前会话都有哪些 profiles

show profiles;

如果想查看最近一次查询开销

show profile

我们也可以查看指定的Query lD的开销，比如show profile for query 2查询结果是一样的。在SHOWPROFILE中我们可以查看不同部分的开销，比如cpu、block.io等:

show profile cup,block io for query 2;

如果是executing比较长就可能是代码哪里没写好，使用explain 继续查询问题

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

converting HEAP to MyISAM: 查询结果太大，内存不够，数据往磁盘上搬了。
creating tmp table: 创建临时表。先拷贝数据到临时表，用完后再删除临时表。
Copying to tmp table on disk:把内存中临时表复制到磁盘上，警惕!
locked 。

如果在show profile诊断结果中出现了以上4条结果中的任何一条，则sql语句需要优化。

分析查询语句：explain

概述

定位了查询慢的SQL之后，我们就可以使用EXPLAIN或DESCRIBE工具做针对性的分析查询语句。DESCRIBE语句的使用方法与EXPLAIN语句是一样的，并且分析结果也是一样的MySQL中有专门负责优化SELECT语句的优化器模块，主要功能: 通过计算分析系统中收集到的统计信息，为客户端请求的Query提供它认为最优的执行计划（他认为最优的数据检索方式，但不见得是DBA认为是最优的，这部分最耗费时间)。
这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。MySQL为我们提供了EXPLAIN语句来帮助我们查看某个查询语句的具体执行计划，大家看懂EXPLAIN语句的各个输出项，可以有针对性的提升我们查询语句的性能。

基本语法

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

explain select ...

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

列名	描述
id	在一个大的查询语句中每个SELECT关键字都对应一个唯一的id
select_type	SELECT关键字对应的那个查询的类型
table	表名
partitions	匹配的分区信息
type	针对单表的访问方法（重要）
possible_keys	可能用到的索引
key	实际上使用的索引
key_len	实际使用到的索引长度
ref	当使用索引列等值查询时，与索引列进行等值匹配的对象信息
rows	预估的需要读取的记录条数
filtered	某个表经过搜索条件过滤后剩余记录条数的百分比
Extra	一些额外的信息

数据准备

建表

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;

设置参数log_bin_trust_function_creators

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

创建函数

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 ;

创建存储过程

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 ;


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 ;

调用存储过程

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

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

explain各列作用

table列

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

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

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

:::info
用到多少表，就会有多少条记录
:::

id

正常来说一个select 一个id ，也有例外的可能，查询优化器做了优化

explain select * from s1 where key1 = 'a';

explain select * from s1 join s2;

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

**union和union all **

explain select * from s1 union select * from s2;

按理说只有两个select,两张表，应该是2个id，2个table。多出来一个是因为union需要使用到临死表。

explain select * from s1 union all select * from s2;

union all 不需要放到临时表中
小结:

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

select_type

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

名称	描述
SIMPLE	Simple SELECT (not using UNION or subqueries)
PRIMARY	Outermost SELECT
UNION	Second or later SELECT statement in a UNION
UNION RESULT	Result of a UNION
SUBQUERY	First SELECT in subquery
DEPENDENT SUBQUERY	First SELECT in subquery, dependent on outer query
DEPENDENT UNION	Second or later SELECT statement in a UNION, dependent on outer query
DERIVED	Derived table
MATERIALIZED	Materialized subquery
UNCACHEABLE SUBQUERY	A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query
UNCACHEABLE UNION	The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY)

simple
1. 不使用union或者子查询

explain select * from s1

连接查询也算simple类型

explain select * from s1 join s2;

primary / union / union result
1. union result

使用union去重时，会创建临时表，该临时表的select_type就是 union result

使用union / union all / 子查询的大查询语句中，他是由几个小查询语句组成，其中最左边的小查询语句的select_type是 primary

使用union / union all / 子查询的大查询语句中，他是由几个小查询语句组成，除了最左边的小查询语句之外，其他的小查询语句的select_type是 union

subquery

子查询语句中的第一个select语句

dependent subquery

子查询语句中的第一个select语句，并且是相关子查询

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。

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

explain select * from (select key1, count(*) as c from s1 group by key1) as derived_s1 where c > 1;

materialized

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

explain select * from s1 where key1 in (select key1 from s2);

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表，并为其插入一条记录:

# myisam中有一个变量统计记录的条数
CREATE TABLE t(value1 INT) ENGINE=MYISAM;
INSERT INTO t VALUES(1);
explain select * from t;

如果是innodb，type就会变成all，因为innodb不会存条数字段

const

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

explain select * from s1 where id = 10005;
explain select * from s1 where key2 = '10066'

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

eq_ref

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

explain select * from s1 join s2 on s1.id = s2.id

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

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

explain select * from s1 where key1 = 'a';

fulltext

全文索引

ref_or_null

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

explain select * from s1 where key1 = 'a' or key1 is null;

index_merge

索引合并（多个索引交集访问，多个索引并集访问等情况）

explain select * from s1 where key1 = 'a' or key3 = 'b';

unique_subquery

是一个索引查找函数，它可以完全替换子查询，提高查询效率。其中查询字段可以是主键或唯一索引，如id/key2

explain select * from s1 where key2 in (select id from s2 where s1.key1 = s2.key1) or key3 = 'a';

index_subquery

和unique_subquery类似，都是索引查找函数，可以替代子查询，提高查询效率。其中其中查询字段是普通索引，如key1,key3

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

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。

explian select * from s1;

一般来说，这些访问方法中除了All这个访问方法外，其余的访问方法都能用到索引，除了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，则没有使用索引。

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

索引只能用一个。所以他要选一个出来用。如果使用or连接，就会走索引连接，即index_merge.

key_len

key_len：实际使用到的索引长度(即：字节数)
key_len越小索引效果越好，短一点效率更高
但是在联合索引里面，命中一次key_len加一次长度。越长代表精度越高，效果越好

explain select * from s1 where id = 10005;
# id的类型是int,4个字节
explain select * from s1 where key2 = 10126;
# id的类型是int,unique索引，因为还可能有一个null值，所以null占一个字段：4+1
explain select * from s1 where key1 = 'a';
# key_len = 303,因为一个字符3个字节，加上null，（100+1）*3=303
explain select * from s1 where key_part1 = 'a';
# idx_key_part(key_part1, key_part2, key_part3） 是3个100的字段合起来的。每一个字段可以为空，所以是101*3 = 303;
explian select * from s1 where key_part1 = 'a' and key_part2 = 'b';
# key_len = 606,这里命中2次联合索引，精度更高，效果更好

key_len的长度计算公式：
:::tips
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

当使用索引列等值查询时，与索引列进行等值匹配的对象信息

explain select * from s1 where key1 = 'a';

explain select * from s1 join s2 on s1.id = s2.id;

explain select * from s1 join s2 on s2.key1 = upper(s1.key1);

row

预估的需要读取的记录条数，值越小越好，数据越有可能在一个页里面，这样io就会更小，通常与filtered一起使用。

explain select * from s1 where key1 > 'z';

filtered

filtered 的值指返回结果的行占需要读到的行(rows 列的值)的百分比。

比如读了100 rows. filtered 是10% 那么就说明还要对着100条进行过滤

explain select * from s1 where key1 > 'z' and common_field = 'a';

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

explain select * from s1 join s2 on s1.key1 = s2.key1 where s1.common_field = 'a';

extra

Extra列是用来说明一些额外信息的，包含不适合在其他列中显示但十分重要的额外信息。我们可以通过这些额外信息来更准确的理解MySQL到底将如何执行给定的查询语句。

no tables used

当查询语句的没有FROM子句时将会提示该额外信息

explain select 1;

impossible where

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

explain select * from s1 where 1 != 1

using where

当我们使用全表扫描来执行对某个表的查询，并且该语句的WHERE子句中有针对该表的搜索条件时

explain select * from s1 where common_field = 'a';

当使用索引访问来执行对某个表的查询，并且该语句的WHERE子句中有除了该索引包含的列之外的其他搜索条件时,也会是这个提示

explain select * from s1 where key1 = 'a' and common_field = 'b';

no matching min / max row

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

explain select min(key1) from s1 where key1 = 'aaaaaaaaaa';

using index

当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用覆盖索引的情况下

explain select key1, id from s1 where key1 = 'a';
# 使用key1二级索引，二级索引的记录中包含主键id，不需要进行回表操作

using index condition

explain select * from s1 where key1 > 'z' and key1 like '%a';

步骤1. 这里key1 > ‘z’ 走了索引，查出了378条数据
步骤2. key1 LIKE ‘%a’; 这个条件依然是 key1 索引,，所以接下来只要在遍历这378个索引，看哪些符合 ‘%a’
步骤3. 通过步骤2 过滤出了有效索引，这就是Using index condition 。
步骤4. 把符合条件的索引，进行回表查询。

完整的说明：
其中的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’这个条件的二级索引记录执行回表操作。

我们说回表操作其实是一个随机IO，比较耗时，所以上述修改虽然只改进了一点点，但是可以省去好多回表操作的成本。MySQL把他们的这个改进称之为**索引条件下推 (**英文名: Index Condition Pushdown )。如果在查询语句的执行过程中将要使用索引条件下推这个特性，在Extra列中将会显示Using index condition

using join buffer(block nested loop)

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

explain select * from s1 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;

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

using filesort

有一些情况下对结果集中的记录进行排序是可以使用到索引的，比如下边这个查询:

EXPLAIN SELECT * FROM s1 ORDER BY key1 LIMIT 10;

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

EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10;

using temporary

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

explain select distinct common_field from s1;

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

小结

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

explain其他输出格式

explain除了上面的传统格式，还有json格式，tree格式。

json格式

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

explain fromat = json select...

explain的column与json的对应关系：

explain format=json select * from s1 inner join s2 on s1.key1 = s2.key1 where s1.common_field = 'a';

"cost_info": {
"read_cost": "937.93",
"eval_cost": "101.52",
"prefix_cost": "1039.45",
"data_read_per_join": "1M"
},

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

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

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

"cost_info": {
"read_cost": "253.80",
"eval_cost": "101.52",
"prefix_cost": "1394.77",
"data_read_per_join": "1M"
},

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

253.80+101.52+1039.45=1394.77

tree格式

TREE格式是8.0.16版本之后引入的新格式，主要根据查询的** 各个部分之间的关系 **和 各部分的执行顺序 来描述如何查询

show warnings的使用

explain select * from s1 where key1 in (select key2 from s2 where common_field = 'a');

使用完explain后紧接着使用show warnings, 可以看到查询优化器真正执行的语句

MySQL监控分析视图-sys schema

sys schema视图摘要

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

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;

风险提示:
通过sys库去查询时，MySQL会消耗大量资源去收集相关信息，严重的可能会导致业务请求被阻塞，从而引起故障。建议生产上不要频繁的去查询sys或者 performance_schema、information_schema来完成监控、巡检等工作。