侧边栏壁纸
博主头像
coydone博主等级

记录学习，分享生活的个人站点

  • 累计撰写 306 篇文章
  • 累计创建 51 个标签
  • 累计收到 0 条评论
标签搜索

目 录CONTENT

文章目录
数据库

性能分析工具的使用

coydone
coydone
2022-01-14 / 0 评论 / 0 点赞 / 326 阅读 / 18,754 字 / 正在检测是否收录...
温馨提示：
本文最后更新于 2022-04-07，若内容或图片失效，请留言反馈。部分素材来自网络，若不小心影响到您的利益，请联系我们删除。

数据库服务器的优化步骤

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

当我们遇到数据库调优问题的时候，该如何思考呢？这里把思考的流程整理成下面这张图。

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

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

首先在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阶段，需要考虑增加服务器，采用读写分离的架构，或者考虑对数据库进行分库分表，比如垂直分库、垂直分表和水平分表等。

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

小结：

查看系统性能参数

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

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的查询成本

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

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

show status like 'last_query_cost';

# 运行时间0.042s，只需要检索一个页
SELECT student_id, class_id, NAME, create_time FROM student_info
WHERE id = 900001;
#运行时间0.046s，需要检索20个页
SELECT student_id, class_id, NAME, create_time FROM student_info
WHERE id BETWEEN 900001 AND 900100;

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

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

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

1、位置决定效率。如果页就在数据库缓冲池中，那么效率是最高的，否则还需要从内存或者磁盘中进行读取，当然针对单个页的读取来说，如果页存在于内存中，会比在磁盘中读取效率高很多。

2、批量决定效率。如果我们从磁盘中对单一页进行随机读，那么效率是很低的（差不多10ms），而采用顺序读取的方式，批量对页进行读取，平均一页的读取效率就会提升很多，甚至要快于单个页面在内存中的随机读取。

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

定位执行慢的SQL

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

它的主要作用是帮助我们发现那些执行时间特别长的SQL查询，并且有针对性地进行优化，从而提高系统的整体效率。当我们的数据库服务器发生阻塞、运行变慢的时候，检查一下慢查询日志，找到那些慢查询，对解决问题很有帮助。比如一条sql执行超过5秒钟，我们就算慢sql，希望能收集超过5秒的sql，结合explain进行全面分析。

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

慢查询日志支持将日志记录写入文件。

开启慢查询日志参数

# 查看慢查询是否已经开启，默认为关闭状态 OFF
show variables like '%slow_query_log';

# 1、开启slow_query_log
set global slow_query_log='ON';

#查看slow_query_log状态，slow_query_log_file目录（慢查询日志文件保存目录）
show variables like '%slow_query_log%';

# 2、修改long_query_time阈值
# 查看慢查询的时间阈值设置，默认为10
show variables like '%long_query_time%';

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

# 3、查看慢查询数目
# 查询当前系统中有多少条慢查询记录
SHOW GLOBAL STATUS LIKE '%Slow_queries%';

补充：配置文件中一并设置参数，如下的方式相较于前面的命令行方式，可以看作是永久设置的方式。

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

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

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

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

慢查询日志分析工具

在生产环境中，如果要手工分析日志，查找、分析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/testdb-slow.log

工作常用参考：

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

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

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

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

关闭慢查询日志

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慢查询日志功能
SET GLOBAL slow_query_log=off;
#（2）重启MySQL服务，使用SHOW语句查询慢查询日志功能信息
SHOW VARIABLES LIKE '%slow%';
#以及
SHOW VARIABLES LIKE '%long_query_time%';

删除慢查询日志

# 使用SHOW语句显示慢查询日志信息
SHOW VARIABLES LIKE 'slow_query_log%';

从执行结果可以看出，慢查询日志的目录默认为MySQL的数据目录，在该目录下手动删除慢查询日志文件即可。使用命令 mysqladmin flush-logs 来重新生成查询日志文件，具体命令如下，执行完毕会在数据目录下重新生成慢查询日志文件。

mysqladmin -uroot -p flush-logs slow

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

查看SQL执行成本

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

# 在会话级别开启Show Profile功能
show variables like 'profiling' ;
# 通过设置 profiling='ON’ 来开启 show profile
set profiling = 'ON';
# 然后执行相关的查询语句。接着看下当前会话都有哪些profiles
show profiles;
# 查看最近一次查询的开销
show profile;
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：显示交换次数开销信息。

日常开发需注意的结论：

  • converting HEAP to MyISAM：查询结果太大，内存不够，数据往磁盘上搬了。

  • Creating tmp table：创建临时表。先拷贝数据到临时表，用完后再删除临时表。

  • Copying to tmp table on disk：把内存中临时表复制到磁盘上，警惕！

  • locked。

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

注意：不过SHOW PROFILE 命令将被弃用，我们可以从 information_schema 中的profiling数据表进行查看。

分析查询语句：EXPLAIN

执行计划概述

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

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

这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。MySQL为我们提供了EXPLAIN语句来帮助我们查看某个查询语句的具体执行计划。

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

官网介绍

版本情况：

  • 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中的信息。

基本语法

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

EXPLAIN SELECT select_options
或者
DESCRIBE SELECT select_options

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

EXPLAIN SELECT 1;

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

EXPLAIN各列作用

1、table

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

2、id

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

EXPLAIN SELECT * FROM s1 INNER JOIN s2; #id相同
#有2个select，有2个id名
EXPLAIN SELECT * FROM s1 
WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a';
#查询优化器可能对涉及子查询的查询语句进行重写，转变为多表查询的操作，有1个id名
EXPLAIN SELECT * FROM s1 
WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field = 'a');
# 有3个id名，其中一个为null值，表示union操作
EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;
# 有2个id名，union操作无需去重，没有临时表
EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2;

3、select_type

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

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

查询语句中不包含UNION或者子查询的查询都算作是SIMPE类型，连接查询也是SIMPLE类型。

EXPLAIN SELECT * FROM s1 INNER JOIN s2; #SIMPE

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

对于包含UTNION或者UNION AL的大查询来说，它是由几个小查询组成的，其中除了最左边的那个小查询以外，其余的小查询的select_type值就是UNION。

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

EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

子查询中如果包含子查询的查询语句不能够转为对应的 semi-join （单表连接）的形式，并且该子查询是不相关子查询。该子查询的第一个SELECT关键字代表的那个查询的select_type就是SUBQUERY。如果是相关子查询，则是DEPENDENT SUBQUERY，select_type为DEPENDENT SUBQUERY的查询可能会被执行多次。

# s1为PRIMARY s2为SUBQUERY
EXPLAIN SELECT * FROM s1 
WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a';

# s1为PRIMARY s2为DEPENDENT SUBQUERY
EXPLAIN SELECT * FROM s1 WHERE key1 IN
 (SELECT key1 FROM s2 WHERE s1.key2 =
s2.key2) OR key3 = 'a';

在包含UNION`或者UNION AL的大查询中，如果各个小查询都依赖于外层查询的话，那除了最左边的那个小查询之外，其余的小查询的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');

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

# PRIMARY <derived2>  ，DERIVED s1
EXPLAIN SELECT * FROM 
(SELECT key1, count(*) as c FROM s1 GROUP BY key1) AS
derived_s1 where c > 1;

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

# 子查询被转化为了物化表
EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2);

UNCACHEABLE SUBQUERY、UNCACHEABLE UNION不常用。

4、partitions（可略）：匹配的分区信息

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

官方文档：https://dev.mysql.com/doc/refman/5.7/en/alter-table-partition-operations.html

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

CREATE TABLE t(i INT)ENGINE=MYISAM;
INSERT INTO t VALUES(1);
EXPLAIN SELECT *FROM t;

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

EXPLAIN SELECT * FROM s1 WHERE id = 10005;

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

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

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

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

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

fulltext：全文索引。

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

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

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

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

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

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，index_subquery与unique_subquery类似，只不过访问子查询中的表时使用的是普通的索引。

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

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

EXPLAIN SELECT * FROM s1 WHERE key1 IN ('a', 'b', 'c');
#或者
EXPLAIN SELECT * FROM s1 WHERE key1 > 'a' AND key1 < 'b';

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

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

ALL：全表扫描

EXPLAIN SELECT * FROM s1;

小结：结果值从最好到最坏依次是：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge >unique_subquery > index_subquery > range > index > ALL ，其中比较重要的几个提取出来（红色）。SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，最好是consts级别。（阿里巴巴开发手册要求）

6、 possible_keys和key

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

7、key_len

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)

8、ref

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

EXPLAIN SELECT * FROM s1 WHERE key1 = 'a'; #const
EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id; #s1.id
EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s2.key1 = UPPER(s1.key1);#func

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

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

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

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

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

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

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

11、Extra

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

# No matching min/max row
#当查询列表处有MIN或者MAX聚合函数，但是并没有符合WHERE子句中的搜索条件的记录时
EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'abcdefg';

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

# Using index condition：索引条件下推
#有些搜索条件中虽然出现了索引列，但却不能使用到索引
EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%b';

# Using join buffer (Block Nested Loop)
#在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySOL一般会为其
#分配一块名叫join buffer的内存块来加快查询速度，也就是基于块的嵌套循环算法
EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.common_field =
 s2.common_field;

# Not exists
#当我们使用左（外）连接时，如果WHERE子句中包含要求被驱动表的某个列等于NUL值
#的搜索条件，而且那个列又是不允许存储NULL值的
EXPLAIN SELECT * FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.id IS
 NULL;

# Using intersect(...) 、 Using union(...) 和 Using sort_union(...)
#Using intersect(...)说明准备使用Intersect索引合并的方式执行查询，
#括号中的...表示需要进行索引合并的索引名称；
#Using union(...)说明准备使用Union索引合并的方式执行查询;
#Using sort_union(...)说明准备使用sort-Union索引合并的方式执行查询。
EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';

# Zero limit
#当LIMIT子句的参数为0时，表示不打算从表中读出任何记录
EXPLAIN SELECT * FROM s1 LIMIT 0;

# Using filesort
#有一些情况下对结果集中的记录进行排序是可以使用到索引的
EXPLAIN SELECT * FROM s1 ORDER BY key1 LIMIT 10; #NULL
#很多情况下排序操作无法使用到索引，只能在内存中（记录较少的时候）或者
#磁盘中（记录较多的时候进行排序，MySQL把这种在内存中或者磁盘上进行排序的方式
#统称为文件排序（英文名: filesort) 。
EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10;# Using filesort

# Using temporary
#在许多查询的执行过程中，MysQL可能会借助临时表来完成一些功能，比如去重、排序之类的，
#比如在执行许多包含DISTINCT、GROUP BY、UNION等子句的查询过程中，如果不能有效利用
#索引来完成查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。
EXPLAIN SELECT DISTINCT common_field FROM s1;
EXPLAIN SELECT common_field, COUNT(*) AS amount FROM s1 GROUP BY
 common_field;
# 执行计划中出现Using temporary并不是一个好的征兆，因为建立与维护临时表
#要付出很大成本的，所以我们最好能使用索引来替代掉使用临时表。比如扫描指定的索引idx_key1即可
#从Extra的Using index的提示里可以看出，下述查询只需要扫描idx_key1索引就可以搞定，不再需要临时表。
EXPLAIN SELECT key1, COUNT(*) AS amount FROM s1 GROUP BY key1; #Using index

小结：

EXPLAIN不考虑各种Cache。

EXPLAIN不能显示MySQL在执行查询时所作的优化工作。

EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况。

部分统计信息是估算的，并非精确值。

EXPLAIN的进一步使用

EXPLAIN四种输出格式

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

1、传统格式

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

2、JSON格式

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

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

EXPLAIN FORMAT=JSON SELECT ....

EXPLAIN 的Column与JSON 的对应关系：（来源于MySQL 5.7文档）

//成本信息
"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 成本。

  • eval_cost是这样计算的：检测 rows × filter 条记录的成本。

  • prefix_cost就是单独查询 s1 表的成本，也就是：read_cost + eval_cost。

  • data_read_per_join表示在此次查询中需要读取的数据量。

3、TREE格式

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

EXPLAIN FORMAT=tree SELECT ....

4、可视化输出

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

按从左到右的连接顺序显示表。红色框表示全表扫描，而绿色框表示使用索引查找。对于每个表，显示使用的索引。还要注意的是，每个表格的框上方是每个表访问所发现的行数的估计值以及访问该表的成本。

SHOW WARNINGS的使用

SHOW WARNINGS \G

SHOW WARNINGS展示出来的信息有三个字段，分别是Level、Code、Message。最常见的就是Code为1003的信息，当Code值为1003时，Message字段展示的信息类似于查询优化器将我们的查询语句重写后的语句。

分析优化器执行计划：trace

OPTIMIZER_TRACE是MySQL5.6引入的一项跟踪功能，它可以跟踪优化器做出的各种决策（比如访问表的方法、各种开销计算、各种转换等），并将跟踪结果记录到INFORMATION_SCHEMA.OPTIMIZER_TRACE 表中。

此功能默认关闭。开启trace，并设置格式为JSON，同时设置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

MySQL监控分析视图：sys schema

关于MySQL的性能监控和问题诊断，我们一般都从performance_schema中去获取想要的数据，在MySQL5.7.7版本中新增sys schema，它将performance_schema和information_schema中的数据以更容易理解的方式总结归纳为视图，其目的就是为了降低查询performance_schema的复杂度，让DBA能够快速的定位问题。

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开头，展示等待事件的延迟情况。

Sys schema视图使用场景

索引情况

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

表相关

# 查询表的访问量
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;
# 查询占用bufferpool较多的表
select object_schema,object_name,allocated,data
from sys.innodb_buffer_stats_by_table order by allocated limit 10;
# 查看表的全表扫描情况
select * from sys.statements_with_full_table_scans where db='dbname';

语句相关

#监控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相关

#查看消耗磁盘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相关

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

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

0
MySQL
  1. qrcode alipay
  2. qrcode weixin
版权归属： coydone
本文链接： https://www.coydone.com/archives/143
许可协议： 本文使用《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》协议授权

评论区