数据库服务器的优化步骤

首先在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数据库服务器的性能参数、执行频率

1
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服务器的连接次数

1
SHOW STATUS LIKE 'Connections';

查询服务器工作时间

1
SHOW STATUS LIKE 'Uptime';

查询MySQL服务器的慢查询次数

1
SHOW STATUS LIKE 'Slow_queries';

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

1
SHOW STATUS LIKE 'Innodb_rows_%';

统计SQL的查询成本：last_query_cost

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

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

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

运行结果（1 条记录，运行时间为 0.042s ）

然后再看下查询优化器的成本，实际上只需要检索一个页 

1
2
3
4
5
6
7
SHOW STATUS LIKE 'last_query_cost';

+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| Last_query_cost | 1.000000 |
+-----------------+----------+

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

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

运行结果（100 条记录，运行时间为 0.046s ）：

然后再看下查询优化器的成本，这时大概需要进行 20 个页的查询。 

1
2
3
4
5
6
SHOW STATUS LIKE 'last_query_cost';
+-----------------+-----------+
| Variable_name   | Value 	  |
+-----------------+-----------+
| Last_query_cost | 21.134453 |
+-----------------+-----------+

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

使用场景：对于比较开销比较有用

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

要考虑数据存放的位置，如果是经常使用的数据就要尽量放到缓冲池中，可以充分利用磁盘的吞吐能力，一次性批量读取数据，这样单个页的读取效率也就得到了提升。

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

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

它的主要作用是帮助我们发现那些执行时间特别长的SQL查询，并且有针对性地进行优化，从而提高系统的整体效率。当数据库服务器发生阻塞、运行变慢时检查一下慢查询日志，找到那些慢查询，对解决问题很有帮助。

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

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

开启慢查询日志参数

开启slow_query_log 

1
2
3
4
-- 查看慢查询日志是否开启，以及慢查询日志文件的位置
show variables like '%slow_query_log';

set global slow_query_log='ON';

修改long_query_time阈值

慢查询的时间阈值设置 

1
show variables like '%long_query_time%';

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

1
2
3
4
5
6
-- 设置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，然后重启MySQL服务器

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

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

查看慢查询数目

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

1
SHOW GLOBAL STATUS LIKE '%Slow_queries%';

慢查询日志分析工具：mysqldumpslow

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

1
mysqldumpslow --help

选项 说明
-a 不将数字抽象成N，字符串抽象成S
-s 排序规则。
c: 访问次数；
l: 锁定时间；
r: 返回记录；
t: 查询时间；
al:平均锁定时间；
ar:平均返回记录数；
at:平均查询时间 （默认方式）
ac:平均查询次数
-t 返回前面多少条的数据；
-g 后边搭配一个正则匹配模式，大小写不敏感的； 
1
2
3
4
5
6
7
8
9
10
11
-- 得到返回记录集最多的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
2
[mysqld]
slow_query_log=OFF

或者，把slow_query_log一项注释掉 或 删除 

1
2
[mysqld]
#slow_query_log =OFF

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

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

临时性方式

停止MySQL慢查询日志功能 

1
SET GLOBAL slow_query_log=off;

重启MySQL服务，使用SHOW语句查询慢查询日志功能信息 

1
2
3
SHOW VARIABLES LIKE '%slow%';
-- 以及
SHOW VARIABLES LIKE '%long_query_time%';

删除慢查询日志

使用SHOW显示慢查询日志信息

1
SHOW VARIABLES LIKE 'slow_query_log%';

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

使用命令mysqladmin flush-logs重新生成慢查询日志文件

1
mysqladmin -uroot -p flush-logs

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

查看 SQL 执行成本：SHOW PROFILE

SHOW PROFILE 是MySQL提供的用于分析当前会话中SQL都做了什么、执行的资源消耗情况。默认处于关闭状态，并保存最近15次的运行结果。

在会话级别开启该功能：

1
show variables like 'profiling';

通过设置profiling=ON开启SHOW PROFILE

1
set profiling = 'ON';

执行相关的查询语句。接着看下当前会话都有哪些 profiles ， 看到当前会话一共有 2 个查询 

1
show profiles;

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

1
show profile

查询指定的Query ID开销

1
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 显示交换次数开销信息

注意

如果在 SHOW PROFILE 诊断结果出现以下情况，需要进行SQL优化

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

分析查询语句：EXPLAIN

概述

定位了查询慢的SQL之后就可以使用EXPLAIN或DESCRIBE工具做针对性的分析查询语句。MySQL中有专门负责优化SELECT语句的优化器模块，通过计算分析系统中收集到的统计信息，为客户端请求的Query提供它认为最优的执行计划。
该执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。MySQL为我们提供EXPLAIN语句来帮助我们查看某个查询语句的具体执行计划，看懂EXPLAIN语句的各个输出项，可以有针对性的提升查询语句的性能。

WHY EXPLAIN

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

基本语法

1
2
3
EXPLAIN SELECT select_options
-- 或者
DESCRIBE SELECT select_options

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

1
EXPLAIN SELECT 1;

注意：执行EXPLAIN时并没有真正的执行该后面的语句，因此可以安全的查看执行计划。

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

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

EXPLAIN 各列作用

table

MySQL规定EXPLAIN语句输出的每条记录都对应着某个单表的访问方法，该条记录的table列代表着该 表的表名（有时不是真实的表名字，可能是简称）。 

1
2
-- 查询的每一行记录都对应着一个单表
EXPLAIN SELECT * FROM s1;

id

的查询语句一般都以 SELECT 关键字开头，比较简单的查询语句里只有一个 SELECT 关键字 

1
SELECT * FROM s1 WHERE key1 = 'a;

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

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

1
EXPLAIN SELECT * FROM s1 INNER JOIN s2;

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

1
2
EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field
= 'a');

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

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

小结

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

select_type

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

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

SIMPLE

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

1
EXPLAIN SELECT * FROM s1;

连接查询也算是SIMPLE类型

1
EXPLAIN SELECT * FROM s1 INNER JOIN s2;

PRIMARY

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

UNION

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

UNION RESULT

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

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

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

SUBQUERY

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

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

DEPENDENT SUBQUERY

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

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

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

DEPENDENT UNION

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

1
2
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

1
2
EXPLAIN SELECT * 
FROM (SELECT key1, COUNT(*) AS c FROM s1 GROUP BY key1) AS derived_s1 WHERE c > 1;

MATERIALIZED

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

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

partitions

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

system

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

比方说我们新建一个MyISAM表，并为其插入一条记录 

1
2
CREATE TABLE t(i int) Engine=MyISAM;
INSERT INTO t VALUES(1);
1
EXPLAIN SELECT * FROM t;

当我们换成新建InnoDB表

1
2
3
CREATE TABLE tt(i INT) ENGINE=INNODB;
INSERT INTO tt VALUES(1);
EXPLAIN SELECT * FROM tt;

const

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

1
EXPLAIN SELECT * FROM s1 WHERE id = 10005;

1
EXPLAIN SELECT * FROM s1 WHERE key2 = 10066;

eq_ref

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

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

ref

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

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

ref_or_null

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

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

index_merge

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

1
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

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

range

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

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

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

index

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

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

`ALL

全表扫描

1
EXPLAIN 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，则没有使用索引。 

1
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比较划算

key_len

key_len表示实际使用到的索引长度（字节数）帮你检查是否充分的利用上了索引，值越大越好，主要针对于联合索引，有一定的参考意义。

1
EXPLAIN SELECT * FROM s1 WHERE id = 10005;

1
EXPLAIN SELECT * FROM s1 WHERE key2 = 10126;

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

1
EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a';

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

1
EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b' AND key_part3 = 'c';

1
EXPLAIN SELECT * FROM s1 WHERE key_part3 = 'a';

ref

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

比如只是一个常数或者是某个列。

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

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

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

rows

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

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

filtered

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

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

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

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

Extra

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

No tables used

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

1
EXPLAIN SELECT 1;

Impossible WHERE

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

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

Using where

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

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

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

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

No matching min/max row

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

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

Using index

当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用覆盖索引的情况下，在Extra列将会提示该额外信息。

比方说下边这个查询中只需要用到idx_key1而不需要回表操作：

1
EXPLAIN SELECT key1,id FROM s1 WHERE key1 = 'a';

Using index condition

有些搜索条件中虽然出现了索引列，但却不能使用到索引

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

Using join buffer

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

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

Not exists

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

1
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索引合并的方式执行查询。
1
EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';

Zero limit

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

1
EXPLAIN SELECT * FROM s1 LIMIT 0;

Using filesort

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

1
EXPLAIN SELECT * FROM s1 ORDER BY key1 LIMIT 10;

很多情况下排序操作无法使用到索引，只能在内存中（记录较少的时候）或者磁盘中（记录较多的时候）进行排序，MySQL把这种在内存中或者磁盘上进行排序的方式统称为文件排序（filesort）。

如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的Extra列中显示Using filesort提示

1
EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10;

Using temporary

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

1
EXPLAIN SELECT DISTINCT common_field FROM s1;

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

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

比如：扫描指定的索引idx_key1即可

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

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

小结

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

EXPLAIN 的进一步使用

EXPLAIN 输出格式

传统格式

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

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

JSON格式

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

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

1
EXPLAIN FORMAT=JSON SELECT ....
1
2
EXPLAIN FORMAT=JSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 
WHERE s1.common_field = 'a';

TREE格式

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

1
2
EXPLAIN FORMAT=tree SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE
s1.common_field = 'a'

SHOW WARNINGS的使用

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

分析优化器执行计划：trace

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

此功能默认关闭。开启trace，并设置格式为JSON，同时设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。

1
2
3
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

测试语句

1
select * from student where id < 10;

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

1
select * from information_schema.optimizer_trace\G

MySQL监控分析视图-sys schema

Sys schema 视图摘要

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

Sys schema 视图使用场景

索引情况 

1
2
3
4
5
6
7
8
9
-- 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
2
3
4
5
6
7
8
9
10
-- 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
2
3
4
5
6
7
8
9
10
11
12
-- 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
2
3
-- 查看消耗磁盘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
2
-- 行锁阻塞情况
select * from sys.innodb_lock_waits;