在数据库调优中，我们的目标就是响应时间更快，吞吐量更大。利用宏观的监控工具和微观的日志分析可以帮我们快速找到调优的思路和方式。

1.数据库服务器优化步骤

数据库调优流程图

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

我们可以通过观察了解数据库整体的运行状态，通过性能分析工具可以让我们了解执行慢的 SQL 都有哪些，查看具体的 SQL 执行计划，甚至是 SQL 执行中的每一步的成本代价，这样才能定位问题所在，找到了问题，再采取相应的行动。

详细解释一下这张图:

首先在 S1 部分，我们需要观察服务器的状态是否存在周期性的波动。如果 存在周期性波动，有可能是周期性节点的原因，比如双十一、促销活动等。这样的话，我们可以通过 A1 这一步骤解决，也就是加缓存，或者更改缓存失效策略。

如果缓存策略没有解决，或者不是周期性波动的原因，我们就需要进一步 分析查询延迟和卡顿的原因。接下来进入S2 这一步，我们需要开启慢查询。慢查询可以帮我们定位执行慢的 SOL 语句。我们可以通过设置long_query_time 参数定义“慢”的闻值，如果 SQL 执行时间超过了long_query_time，则会认为是慢查询。当收集上来这些慢查询之后，我们就可以通过分析工具对慢查询日志进行分析。

在S3 这一步骤中，我们就知道了执行慢的 SQL，这样就可以针对性地用 EXPLAIN 查看对应 SQL 语句的执行计划，或者使用 show profile 查看 SQL中每一个步骤的时间成本。这样我们就可以了解 SQL 查询慢是因为执行时间长，还是等待时间长。

如果是 SOL 等待时间长，我们进入 A2 步骤。在这一步中，我们可以 调优服务器的参数，比如适当增加数据库缓冲池等。如果是 SQL 执行时间长，就进入 A3 步骤，这一步中我们需要考虑是索引设计的问题?还是查询关联的数据表过多?还是因为数据表的字段设计问题导致了这一现象。然后在这些维度上进行对应的调整。

如果 A2和 A3 都不能解决问题，我们需要考虑数据库自身的 SOL 查询性能是否已经达到了瓶颈，如果确认没有达到性能瓶颈，就需要重新检查，重复以上的步骤。如果已经达到了 性能瓶颈，进入 A4 阶段，需要考虑 增加服务器，采用 读写分离的架构，或者考虑对数据库进行 分库分表，比如垂直分库、垂直分表和水平分表等。

以上就是数据库调优的流程思路。如果我们发现执行 SQL 时存在不规则延迟或卡顿的时候，就可以采用分析工具帮我们定位有问题的 SQL，这三种分析工具你可以理解是 SQL 调优的三个步骤: 慢查询、EXPLAIN 和 SHOW PROFILING。

小结：

2.查看系统性能参数

在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: 插入操作的次数。对于批量插入的INSERT 操作，只累加一次；
• Com_update:更新操作的次数；
• Com_delete:删除操作的次数；

举例：

#若查询MySQL服务器的连接次数，则可以执行如下语句:
SHOW STATUS LIKE 'Connections';
#若查询服务器工作时间，则可以执行如下语句:
SHOW STATUS LIKE 'Uptime';
#若查询MySQL服务器的慢查询次数，则可以执行如下语句:
SHOW STATUS LIKE 'Slow_queries';

慢查询次数参数可以结合慢查询日志找出慢查询语句，然后针对慢查询语句进行 表结构优化 或者 查询语句优化。

3.统计SOL的查询成本: last_query_cost

一条 SQL 查询语句在执行前需要确定查询执行计划，如果存在多种执行计划的话，MySQL 会计算每个执行计划所需要的成本，从中选择 成本最小的一个作为最终执行的执行计划。

如果我们想要查看某条 SQL 语句的查询成本，可以在执行完这条 SQL 语句之后，通过查看当前会话中的last_query_cost 变量值来得到当前查询的成本。它通常也是我们评价一个查询的执行效率 的一个常用指标。这个查询成本对应的是 SQL 语句所需要读取的页的数量。

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

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

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

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

4.定位执行慢的 SQL: 慢查询日志

MySQL的慢查询日志，用来记录在MySQL中 响应时间超过阀值 的语句，具体指运行时间超过 long_query_time 值的SQL，则会被记录到慢查询日志中。 long_query_time的默认值为 10，意思是运行10秒以上 (不含10秒)的语句，认为是超出了我们的最大忍耐时间值。

默认情况下，MySQL数据库 没有开启慢查询日志，需要我们手动来设置这个参数。如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。

4.1开启慢查询日志参数

1.开启slow_query_log

查看慢查询是否开启：

show variables like '%slow_query_log';

打开慢查询日志，注意设置变量值的时候需要使用 global，否则会报错

set global slow_query_log='ON';

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

此时慢查询分析已经开启，同时文件保存在/var/lib/mysql/localhost-slow.log文件中

2.修改long_query_time闽值

查看慢查询的时间阈值设置：

show variables like '%long_query_time%';

想把时间缩短，比如设置为1秒，可以这样设置:

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

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/localhost-slow.log	#慢查询日志的目录和文件名信息
long_query_time=3	#设置慢查询的阈值为3秒，超出此设定的SQL被记录到慢查询日志
log_output=FILE

如果不指定存储路径，慢查询日志将默认存储到MySOL数据库的数据文件夹下。如果不指定文件名，默认文件名为hostname-slow.log。

4.2查看慢查询数目

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

SHOW GLOBAL STATUS LIKE '%Slow_queries%';

补充说明:

除了上述变量，控制慢查询日志的还有一个系统变量: min_examined_row_limit。这个变量的意思是，查询扫描过的最少记录数。这个变量和查询执行时间，共同组成了判别一个查询是否是慢查询的条件。如果查询扫描过的记录数大于等于这个变量的值，并且查询执行时间超过long_query_time的值，那么这个查询就被记录到慢查询日志中;反之，则不被记录到慢查询日志中。

这个值默认是0。与long_query_time=10 合在一起，表示只要查询的执行时间超过 10 秒钟，哪怕一个记录也没有扫描过，都要被记录到慢查询日志中。你也可以根据需要，通过修改“my.ini”文件，来修改查询时长，或者通过SET指令，用SQL 语句修改“min_examined_row_limit”的值。

4.3慢查询日志分析工具：mysqldumpslow

查看mysqldumpslow的帮助信息

mysqldumpslow --help

mysqldumpslow命令的具体参数如下:

• -a：不将数字抽象成N，字符串抽象成S
• -s：是表示按照何种方式排序
  • c：访问次数
  • l：锁定时间
  • r：返回记录
  • t：查询时间
  • al：平均锁定时间
  • ar：平均返回记录数
  • at：平均查询时间(默认方式)
  • ac：平均查询次数
• -t：返回前面多少条的数据
• -g：后面搭配一个正则匹配模式，大小写不敏感

工作常用参考：

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

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

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

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

4.4关闭慢查询日志

MySOL服务器停止慢查询日志功能有两种方法：

方式1:永久性方式

[mysqld]
slow_query_log=OFF
#或者，把slow_query_log=OFF注释或删除

重启MySOL服务，执行如下语句查询慢日志功能

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

方式2:临时性方式

使用SET语句来设置

(1) 停止MySOL慢查询日志功能，具体SOL语句如下

SET GLOBAL slow_query_log=off;

(2) 重启MySQL服务，使用SHOW语句查询慢查询日志功能信息，具体SQL语句如下

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

4.5删除慢查询日志

使用SHOW语句显示慢查询日志信息，具体SQL语句如下。

SHOW VARIABLES LIKE 'slow_query_log%';

从执行结果可以看出，慢查询日志的目录默认为MySOL的数据目录，在该目录下 手动删除慢查询日志文件 即可。

使用命令mysqladmin flush-logs 来重新生成查询日志文件，具体命令如下，执行完毕会在数据目录下重新生成慢查询日志文件。

mysqladmin -uroot -p flush-logs slow

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

5.查看SQL执行成本：SHOW PROFILE

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

在会话级别开启这个功能：

show variables like 'profiling';

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

通过设置profiling=‘ON’;

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

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

show profiles;

查看最近一次查询的消耗

show profile;

也可以查看指定的Query_lD的开销，比如show profile for query 13查询结果是一样的，在SHOW PROFILE中我们可以查看不同部分的开销，比如cpu、block.io等：

show profile cpu,block io for query 13;

show profile的常用查询参数：

• ALL：显示所有的开销信息
• BLOCK IO：显示块IO开销
• CONTEXT SWITCHES：上下文切换开销
• 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

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

6.分析查询语句：EXPLAIN

6.1概述

定位了查询慢的 SQL 之后，我们就可以使用 EXPLAIN 或 DESCRIBE 工具做针对性的分析查询语句。DESCRIBE语句的使用方法与EXPLAIN语句是一样的，并且分析结果也是一样的。

MySOL中有专门负责优化SELECT语句的优化器模块，主要功能: 通过计算分析系统中收集到的统计信息，为客户端请求的Query提供它认为最优的 执行计划 (他认为最优的数据检索方式，但不见得是DBA认为是最优的，这部分最耗费时间)。

这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。MySQL为我们提供了 EXPLAIN 语句来帮助我们查看某个查询语句的具体执行计划，大家看懂EXPLAIN 语句的各个输出项，可以有针对性的提升我们查询语句的性能。

能做什么

• 表的读取顺序
• 数据读取操作的操作类型
• 哪些索引可以使用
• 哪些索引被实际使用
• 表之间的引用
• 每张表有多少行被优化器查询

版本情况

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

6.2基本语法

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

EXPLAIN SELECT select_options;
或者
DESCRIBE SELECT select_options;

看某个查询的执行计划的，可以在具体的查询语句前边加一个EXPLAIN

EXPLAIN SELECT 1;

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

注意

• 执行EXPLAIN SELECT、EXPLAIN DELETE、EXPLAIN UPDATE语句并不会真正的执行SQL语句，只是查看执行计划而已。
• 更多关注的是EXPLAIN SELECT

6.3EXPLAIN各列作用

table

• EXPLAIN SELECT查出来有多少行记录就有多少张表（包含临时表）
• 一行记录就对应着一张表
• 查询中有可能出现临时表，比如UNION

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

下列查询中S2为驱动表，S1为被驱动表，优化器来判断哪张表为驱动表，在上为驱动表

id

• 在一个大的查询语句中每个SELECT关键字都对应一个唯一的id
• 有多少个id，就代表有多少个SELECT
• 查询优化器可能对涉及子查询的查询语句进行重写，转变为多表查询操作，那么自然就少了一个SELECT，因此并不是SQL语句中有多少个SELECT就有多少个SELECT

PS：一般来讲，子查询的效率不然多表连接查询

SELECT关键字都对应一个唯一的id

查询优化器可能对涉及子查询的查询语句进行重写,转变为多表查询的操作

Union去重

UNION ALL 不去重，因此不会有临时表

总结

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

select_type

一条大的查询语句里面可以包含若干个SELECT关键字，每个SELECT关键字代表着一个小的查询语句，而每个SELECT关键字的FROM字句都可以包含若干张表（这些表用来做连接查询），每一张表都对应着执行计划输出中的一条记录，对于在同一个SELECT关键字中的表来说，他们的id值是相同的。

MySQL为每一个SELECT关键字代表的小查询都定义了一个称之为select_type的属性，意思是我们只要知道了某个小查询的select_type属性，就知道了这个小查询在整个大查询中扮演了一个什么角色。

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

连接查询也算是SIMPLE类型

对于包含UNION或者UNION ALL或者子查询的大查询来说，它是由几个小查询组成的，

其中最左边的那个（子查询外边的那个）查询的select_type值就是PRIMARY

除了最左边的那个小查询以外，其余的小查询的select_type值就是UNION

MySQL选择使用临时表来完成UNION查询的去重工作，针对该临时表的查询的select_type就是 UNION RESULT

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

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

注意的是，select_type为DEPENDENT SUBQUERY的查询可能会被执行多次

在包含UNION或者UNION ALL的大查询中，如果各个小查询都依赖于外层查询的话，那除了 最左边的那个小查询之外，其余的小查询的select_type的值就是DEPENDENT UNION

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

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

partitions (可略)

代表分区表中的命中情况，非分区表，该项为NULL。一般情况下我们的查询语句的执行计划的partitions列的值都是NULL。

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。

当表中只有一条记录并且该表使用的存储引擎的统计数据是精确的【MyISAM表中有一个变量记录了count(*)的值】，比如MyISAM、Memory， 那么对该表的访问方法就是system

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

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

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

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

单表访问方法时在某些场景下可以使用Intersection、Union、Sort-Union这三种索引合并的方式来执行查询 type为index_merge【where必须使用OR关键字】

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

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

当我们可以使用索引覆盖，但需要扫描全部的索引记录时，该表的访问方法就是index覆盖索引（索引覆盖）：查询语句的WHERE条件中使用的是二级索引，并且只查询索引列的值，那么就不需要进行回表操作

全表扫描，使用all

possible_keys和key

possible_keys和key：可能用到的索引 和 实际上使用的索引

key_len

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

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

rows

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

filtered

某个表经过搜索条件过滤后剩余记录条数的百分比

如果使用的是索引执行的单表扫描，那么计算时需要估计出满足除使用 到对应索引的搜索条件外的其他搜索条件的记录有多少条

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

Extra

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

索引覆盖：查询语句的WHERE条件中使用的是二级索引，并且只查询索引列的值，那么就不需要进行回表操作。

Using index

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

 
 #11. Extra:一些额外的信息
 #更准确的理解MySQL到底将如何执行给定的查询语句
 
 
 #当查询语句的没有`FROM`子句时将会提示该额外信息
 EXPLAIN SELECT 1;
 
 
 #查询语句的`WHERE`子句永远为`FALSE`时将会提示该额外信息
 EXPLAIN SELECT * FROM S1 WHERE 1 != 1;
 
 
 #当我们使用全表扫描来执行对某个表的查询，并且该语句的`WHERE`
 #子句中有针对该表的搜索条件时，在`Extra`列中会提示上述额外信息。
 EXPLAIN SELECT * FROM S1 WHERE common_field = 'a';
 
 
 #当使用索引访问来执行对某个表的查询，并且该语句的`WHERE`子句中
 #有除了该索引包含的列之外的其他搜索条件时，在`Extra`列中也会提示上述额外信息。
 EXPLAIN SELECT * FROM S1 WHERE key1 = 'a' AND common_field = 'a';
 
 
 #当查询列表处有`MIN`或者`MAX`聚合函数，但是并没有符合`WHERE`子句中
 #的搜索条件的记录时，将会提示该额外信息
 EXPLAIN SELECT MIN(key1) FROM S1 WHERE key1 = 'abcdefg';
 
 EXPLAIN SELECT MIN(key1) FROM S1 WHERE key1 = 'NlPros'; #NlPros 是 s1表中key1字段真实存在的数据
 
 #select * from S1 limit 10;

 # 覆盖索引（索引覆盖）：查询语句的WHERE条件中使用的是二级索引，并且只查询索引列的值，那么就不需要进行回表操作。
 

 #当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以
 #使用覆盖索引的情况下，在`Extra`列将会提示该额外信息。比方说下边这个查询中只
 #需要用到`idx_key1`而不需要回表操作：
 EXPLAIN SELECT key1,id FROM S1 WHERE key1 = 'a';
 
 
 #有些搜索条件中虽然出现了索引列，但却不能使用到索引
 #理解索引条件下推
 EXPLAIN SELECT * FROM S1 WHERE key1 > 'z' AND key1 LIKE '%a';
 
 
 #在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为
 #其分配一块名叫`join buffer`的内存块来加快查询速度，也就是我们所讲的`基于块的嵌套循环算法`
 #见课件说明
 EXPLAIN SELECT * FROM S1 INNER JOIN S2 ON S1.common_field = S2.common_field;
 
 
 #当我们使用左（外）连接时，如果`WHERE`子句中包含要求被驱动表的某个列等于`NULL`值的搜索条件，
 #而且那个列又是不允许存储`NULL`值的，那么在该表的执行计划的Extra列就会提示`Not exists`额外信息
 EXPLAIN SELECT * FROM S1 LEFT JOIN S2 ON S1.key1 = S2.key1 WHERE S2.id IS NULL;
 
 
 #如果执行计划的`Extra`列出现了`Using intersect(...)`提示，说明准备使用`Intersect`索引
 #合并的方式执行查询，括号中的`...`表示需要进行索引合并的索引名称；
 #如果出现了`Using union(...)`提示，说明准备使用`Union`索引合并的方式执行查询；
 #出现了`Using sort_union(...)`提示，说明准备使用`Sort-Union`索引合并的方式执行查询。
 EXPLAIN SELECT * FROM S1 WHERE key1 = 'a' OR key3 = 'a';
 
 
 #当我们的`LIMIT`子句的参数为`0`时，表示压根儿不打算从表中读出任何记录，将会提示该额外信息
 EXPLAIN SELECT * FROM S1 LIMIT 0;
 
 
 #有一些情况下对结果集中的记录进行排序是可以使用到索引的。
 #比如：
 EXPLAIN SELECT * FROM S1 ORDER BY key1 LIMIT 10;
 
 
 #很多情况下排序操作无法使用到索引，只能在内存中（记录较少的时候）或者磁盘中（记录较多的时候）
 #进行排序，MySQL把这种在内存中或者磁盘上进行排序的方式统称为文件排序（英文名：`filesort`）。
 
 #如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的`Extra`列中显示`Using filesort`提示
 EXPLAIN SELECT * FROM S1 ORDER BY common_field LIMIT 10;
 
 
 #在许多查询的执行过程中，MySQL可能会借助临时表来完成一些功能，比如去重、排序之类的，比如我们
 #在执行许多包含`DISTINCT`、`GROUP BY`、`UNION`等子句的查询过程中，如果不能有效利用索引来完成
 #查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。如果查询中使用到了内部的临时表，在执行
 #计划的`Extra`列将会显示`Using temporary`提示
 EXPLAIN SELECT DISTINCT common_field FROM S1;
 
 #EXPLAIN SELECT DISTINCT key1 FROM s1;
 
 #同上。
 EXPLAIN SELECT common_field, COUNT(*) AS amount FROM S1 GROUP BY common_field;
 
 #执行计划中出现`Using temporary`并不是一个好的征兆，因为建立与维护临时表要付出很大成本的，所以
 #我们`最好能使用索引来替代掉使用临时表`。比如：扫描指定的索引idx_key1即可
 EXPLAIN SELECT key1, COUNT(*) AS amount FROM S1 GROUP BY key1;

小结

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

EXPLAIN的进一步使用

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

传统格式

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

JSON格式

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

EXPLAIN FORMAT=JSON SELECT ...

EXPLAIN FORMAT = JSON SELECT * FROM S1 INNER JOIN S2 ON S1.key1 = S2.key2 WHERE S1.common_field = 'a';

TREE格式

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

可视化输出

可视化输出，可以通过MySQL Workbench可视化查看MySOL的执行计划。通过点击Workbench的放大镜图标，即可生成可视化的查询计划。

SHOW WARNINGS的使用

在我们使用EXPLAIN 语句查看了某个查询的执行计划后，紧接着还可以使用 SHOW WARNINGS 语句查看与这个查询的执行计划有关的一些扩展信息，比如这样:

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

MySQL监控分析视图-sys schema

关于MvSOL的性能监控和问题诊断，我们一般都从performance_schema中去获取想要的数据，在MySQL5.7.7版本中新增sys schema，它将performance_schema和information_schema中的数据以更容易理解的方式总结归纳为”视图”，其目的就是为了降低查询performance_schema的复杂度，让DBA能够快速的定位问题。下面看看这些库中都有哪些监控表和视图，掌握了这些，在我们开发和运维的过程中就起到了事半功倍的效果。

Sys schema视图摘要

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

风险提示

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