性能分析工具的使用
MySQL
|
|
|
112

13967 字
|
1.4 小时

性能分析工具的使用

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

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

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

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

image-20231009150219049

我们可以通过观察了解数据库整体的运行状态，通过性能分析工具可以让我们了解执行慢的 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

小结：

image-20231009150307323

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

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

再比如，如下的指令可以查看相关的指令情况：

SHOW STATUS LIKE 'Innodb_rows_%';

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

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

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

以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.01s ）

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

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.01s ）：

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

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

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

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

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

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

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

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

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

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

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

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

4.1 开启慢查询日志参数

1. 开启 slow_query_log

在使用前，我们需要先查下慢查询是否已经开启，使用下面这条命令即可：

show variables like '%slow_query_log';

image-20231009162956032

我们可以看到 slow_query_log=OFF，我们可以把慢查询日志打开，注意设置变量值的时候需要使用 global，否则会报错：

set global slow_query_log='ON';

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

image-20231009163353085

你能看到这时慢查询分析已经开启，同时文件保存在 /var/lib/mysql/centos-slow.log 文件中

2. 修改long_query_time阈值

接下来我们来看下慢查询的时间阈值设置，使用如下命令：

show variables like '%long_query_time%';

image-20231009163718214

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

# 即更改global 也更改了session变量
mysql> set long_query_time = 1;
mysql> show variables like '%long_query_time%';

image-20231009165337287

补充:配置文件中一并设置参数

如下的方式相较于前面的命令行方式，可以看作是永久设置的方式

修改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

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

4.2 查看慢查询数目

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

SHOW GLOBAL STATUS LIKE '%Slow_queries%';

4.3 案例演示

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

4.4 测试及分析

1.测试

mysql> SELECT * FROM student WHERE stuno = 3455655;
+---------+---------+--------+------+---------+
| id      | stuno   | name   | age  | classId |
+---------+---------+--------+------+---------+
| 3355654 | 3455655 | ThffmR |   54 |     932 |
+---------+---------+--------+------+---------+
1 row in set (6.00 sec)

mysql> SELECT * FROM student WHERE name = 'ThffmR';
+---------+---------+--------+------+---------+
| id      | stuno   | name   | age  | classId |
+---------+---------+--------+------+---------+
|  143034 |  243035 | THFfMr |   50 |     255 |
|  298367 |  398368 | ThffmR |   55 |     965 |
|  996481 | 1096482 | tHfFMR |   98 |     368 |
| 1205544 | 1305545 | THFfMr |   53 |     392 |
| 3125095 | 3225096 | thFFmr |   96 |     749 |
| 3250051 | 3350052 | THFfMr |   53 |     380 |
| 3251094 | 3351095 | thFFmr |  100 |     940 |
| 3355654 | 3455655 | ThffmR |   54 |     932 |
| 3699915 | 3799916 | ThffmR |   54 |     931 |
| 3850133 | 3950134 | ThffmR |   54 |     930 |
+---------+---------+--------+------+---------+
10 rows in set (6.18 sec)

从上面的结果可以看出来，查询学生编号为“3455655”的学生信息花费时间为6.00秒。查询学生姓名为“ThffmR”的学生信息花费时间为6.18秒。已经达到了秒的数量级，说明目前查询效率是比较低的，下面的小节我们分析一下原因

2.分析

show status like 'slow_queries';

补充说明:

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

mysql> show variables like 'min%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| min_examined_row_limit | 0     |
+------------------------+-------+
1 row in set (0.00 sec)

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

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

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

查看mysqldumpslow的帮助信息 

mysqldumpslow --help

image-20231009172914503

mysqldumpslow 命令的具体参数如下：

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

举例：我们想要按照查询时间排序，查看前五条 SQL 语句，这样写即可： 

mysqldumpslow -a -s t -t 5 /var/lib/mysql/centos-slow.log

image-20231009173348906

工作常用参考：

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

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

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

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

4.6 关闭慢查询日志

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

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

4.7 删除慢查询日志

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

SHOW VARIABLES LIKE 'slow_query_log%';

image-20231009194608323

从执行结果可以看出，慢查询日志的目录默认为MySQL的数据目录，在该目录下手动删除慢查询日志文件即可。使用命令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';

image-20231009195028266

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

set profiling = 'ON';

image-20231009195215338

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

show profiles;

image-20231009200215098

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

show profile;

image-20231009200246231

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

show profile cpu,block io for query 2;

image-20231009200513341

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

show profile的常用查询参数：

  1. ALL：显示所有的开销信息

  2. BLOCK IO：显示块IO开销

  3. CONTEXT SWITCHES：上下文切换开销

  4. CPU：显示CPU开销信息

  5. IPC：显示发送和接收开销信息

  6. MEMORY：显示内存开销信息

  7. PAGE FAULTS：显示页面错误开销信息

  8. SOURCE：显示和Source_function，Source_file，Source_line相关的开销信息

  9. SWAPS：显示交换次数开销信息

日常开发需注意的结论:

  1. converting HEAP to MyISAM: 查询结果太大，内存不够，数据往磁盘上搬了
  2. creating tmp table: 创建临时表。先拷贝数据到临时表，用完后再删除临时表
  3. Copying to tmp table on disk:把内存中临时表复制到磁盘上，警惕!
  4. locked
    如果在show profile诊断结果中出现了以上4条结果中的任何一条，则sql语句需要优化

注意:

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

6. 分析查询语句：EXPLAIN

6.1 概述

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

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

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

1.能做什么?

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

2.版本情况

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

image-20231010150946209

6.2 基本语法

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

EXPLAIN SELECT select_options
# 或者 两个是一样的
DESCRIBE SELECT select_options

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

EXPLAIN SELECT 1;

image-20231010151359320

输出的上述信息就是所谓的执行计划。在这个执行计划的辅助下，我们需要知道应该怎样改进自己的查询语句以使查询执行起来更高效。其实除了以SELECT开头的查询语句，其余的DELETE、INSERT、REPLACE以及UPDATE语句等都可以加上EXPLAIN,用来查看这些语句的执行计划，只是平时我们对SELECT语句更感兴趣

注意：

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

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

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

6.3 数据准备

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); # id 10002~20001

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

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

6.4 EXPLAIN各列作用

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

（1）table

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

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

image-20231010154525112

这个查询语句只涉及对 s1 表的单表查询，所以EXPLAIN输出中只有一条记录，其中的 table 列的值为 s1，表明这条记录是对 s1 表的单表访问

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

image-20231010154842004

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

（2）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';

但是下面两种情况下在一条查询语句中会出现多个SELECT关键字：

  • 查询中包含子查询的情况

比如下面这个查询语句中就包含2个SELECT关键字：

 SELECT * FROM s1 
 WHERE key1 IN (SELECT key3 FROM s2);
  • 查询中包含UNION语句的情况

比如下面这个查询语句中也包含2个SELECT关键字：

 SELECT * FROM s1 UNION SELECT * FROM s2;

查询语句中每出现一个SELECT关键字，MySQL就会为它分配一个唯一的id值。这个id值就是EXPLAIN语句的第一个列，比如下面这个查询中只有一个SELECT关键字，所以EXPLAIN的结果中也就只有一条id列为1的记录：

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

image-20231010160329978

对于连接查询来说，一个SELECT关键字后边的FROM字句中可以跟随多个表，所以在连接查询的执行计划中，每个表都会对应一条记录，但是这些记录的id值都是相同的，比如：

EXPLAIN SELECT * FROM s1 INNER JOIN s2;

image-20231010160710685

可以看到，上述连接查询中参与连接的 s1 和 s2 表分别对应一条记录，但是这两条记录对应的id都是1。这里需要大家记住的是，在连接查询的执行计划中，每个表都会对应一条记录，这些记录的 id 列的值是相同的，出现在前边的表表示驱动表，出现在后面的表表示被驱动表。所以从上边的 EXPLAIN输出中我们可以看到，查询优化器准备让 s1 表作为驱动表，让 s2 表作为被驱动表来执行查询

对于包含子查询的查询语句来说，就可能涉及多个SELECT关键字，所以在包含子查询的查询语句的执行计划中，每个SELECT关键字都会对应一个唯一的 id 值，比如这样：

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

image-20231010161200490

从输出结果中我们可以看到：s1表在外层查询中，外层查询有一个独立的SELECT关键字，所以第一条记录的id值就是1，s2表在子查询中，子查询有一个独立的SELECT关键字，所以第二条记录的id值就是2

但是这里大家需要特别注意，查询优化器可能对涉及子查询的查询语句进行重写，从而转换为连接查询。所以如果我们想知道查询优化器对某个包含子查询的语句是否进行了重写，直接查看执行计划就好了，比如说：

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

image-20231010161923791

可以看到，虽然我们的查询语句是一个子查询，但是执行计划中 s1 和 s2 表对应的记录的id值全部是 1，这就表明查询优化器将子查询转换为了连接查询

  • 特殊情况 2：union 去重临时表

对于包含UNION子句的查询语句来说，每个SELECT关键字对应一个id值也是没错的，不过还是有点特别的东西，比方说下面的查询：

# UNION去重
EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

image-20231010164948211

这个语句的执行计划的第三条记录是什么？为何id值是NULL,而且table列也很奇怪？

UNION：它会把多个查询的结果集合并起来并对结果集中的记录进行去重，怎么去重呢？MySQL使用的是内部的临时表。正如上面的查询计划中所示，UNION子句是为了把id为1的查询和id为2的查询的结果集合并起来并去重，所以在内部创建了一个名为<union1,2>的临时表（就是执行计划第三条记录的table列的名称），id为NULL表明这个临时表是为了合并两个查询的结果集而创建的

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

# UNION ALL 不去重，所以不需要放在临时表里面
EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2;

image-20231010165725090

小结:

  • id 如果相同，可以认为是一组，从上往下顺序执行
  • 在所有组中，id 值越大，优先级越高，越先执行 （类似递归，先执行内层的操作）
  • 关注点：每个id表示一趟独立的查询，一个SQL的查询趟数越少越好

（3）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

查询语句中不包含UNION或者子查询的查询都算作是SIMPLE类型，比方说下面这个单表查询select_type的值就是SIMPLE:

EXPLAIN SELECT * FROM s1;

image-20231010175119593

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

EXPLAIN SELECT * FROM s1 INNER JOIN s2;

image-20231010175224463

  • PRIMARY

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

  • UNION

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

  • UNION RESULT

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

EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

image-20231010175815030

从结果中可以看到，最左边的小查询SELECT * FROM s1对应的是执行计划中的第一条记录，它的select_type的值就是PRIMARY

  • SUBQUERY

如果包含子查询的查询语句不能够转为对应的semi-join的形式，并且该子查询是不相关子查询（即子查询中没有用到外层查询的表），并且查询优化器决定采用将该子查询物化的方案来执行该子查询时，该子查询的第一个SELECT关键字代表的那个查询的select_type就是SUBQUERY

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

image-20231010182436701

  • DEPENDENT SUBQUERY

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

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

image-20231010182903854

select_type为DEPENDENT SUBQUERY的查询可能会被执行多次

  • DEPENDENT UNION

    在包含UNION或者UNION ALL的大查询中，如果各个小查询都依赖于外层查询的话，那除了最左边的那个小查询之外，其余的小查询的select_type的值就是DEPENDENT UNION（这里优化器会重构成exist）

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

image-20231010183226090

  • DERIVED

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

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

image-20231010184515022

从执行计划中可以看出，id 为 2 的记录就代表子查询的执行方式，它的select_type是DERIVED, 说明该子查询是以物化的方式执行的。id 为 1 的记录代表外层查询，它的 table 列显示的是derived2，表示该查询时针对将派生表物化之后的表进行查询的

  • MATERIALIZED

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

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

image-20231010185023716

（4）partitions (略)

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

（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 (因为有专门的空间记录 count 值)、Memory，那么对该表的访问方法就是 system。比方说我们新建一个 MyISAM 表，并为其插入一条记录：

mysql> CREATE TABLE t(i int) Engine=MyISAM;
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO t VALUES(1);
Query OK, 1 row affected (0.00 sec)

然后我们看一下查询这个表的执行计划：

EXPLAIN SELECT * FROM t;

image-20231010211402397

这里如果是Innodb会变成ALL ， 因为Innodb系统没有存条数字段

  • const

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

EXPLAIN SELECT * FROM s1 WHERE id = 10005;

image-20231010212055651

  • eq_ref

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

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

image-20231010212502270

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

  • ref

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

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

image-20231010212829017

tips: 类型相同才可以走索引

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

  • fulltext

    全文索引

  • ref_or_null

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

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

image-20231010213159393

  • index_merge

一般情况下对于某个表的查询只能使用到一个索引，但单表访问方法时在某些场景下可以使用 Interseation、union、Sort-Union 这三种索引合并的方式来执行查询，只能使用 OR，不能使用 AND

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

image-20231010213906027

从执行计划的type列的值是index_merge就可以看出，MySQL 打算使用索引合并的方式来执行对 s1 表的查询。如果是使用and，则type = ref，只使用到inx_key1索引

  • unique_subquery

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

image-20231010214228632

  • index_subquery

index_subquery 与 unique_subquery 类似，只不过访问子查询中的表时使用的是普通的索引

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

image-20231010214947888

  • range

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

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

image-20231010215129676

或者：

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

image-20231010215205792

  • index

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

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

image-20231010215336450

上述查询中的所有列表中只有 key_part2 一个列，而且搜索条件中也只有 key_part3 一个列，这两个列又恰好包含在 idx_key_part 这个索引中，可是搜索条件 key_part3 不能直接使用该索引进行 ref 和 range 方式的访问，只能扫描整个 idx_key_part 索引的记录，所以查询计划的 type 列的值就是 index

再一次强调，对于使用 InnoDB 存储引擎的表来说，二级索引的记录只包含索引列和主键列的值，而聚簇索引中包含用户定义的全部列以及一些隐藏列，所以扫描二级索引的代价比直接全表扫描，也就是扫描聚簇索引的代价更低一些

覆盖索引不止在 type = index 时才有，只要不用回表就能查到想要的字段，就都叫覆盖索引

eg: select key1 from s1 where key1 = 'a';

其中 key1 是一个二级索引，但是只需要查 key1，所以并不需要回表

  • ALL

全表扫描

EXPLAIN SELECT * FROM s1;

image-20231010215908052

一般来说，这些访问方法中除了ALL这个访问方法外，其余的访问方法都能用到索引。除了index_merge访问方法外，其余的访问方法都最多只能用到一个索引

小结:

结果值从最好到最坏依次是：

system > const > eq_ref > ref >

fulltext > ref_or_null > index_merge >unique_subquery > index_subquery > range >

index > ALL

SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，最好是 const 级别（阿里巴巴开发手册要求）

（6）possible_keys和key

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

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

image-20231010224011510

上述执行计划的 possible_keys 列的值是 idx_key1，idx_key3，表示该查询可能使用到 idx_key1, idx_key3 两个索引，然后 key 列的值是 idx_key3，表示经过查询优化器计算使用不同索引的成本后，最后决定采用 idx_key3

（7）key_len ☆

  • key_len：实际使用到的索引长度(即：字节数)
  • 在联合索引里面，key_len越长代表精度越高，效果越好
EXPLAIN SELECT * FROM s1 WHERE id = 10005;

image-20231010224527943

int 占用 4 个字节

EXPLAIN SELECT * FROM s1 WHERE key2 = 10126;

image-20231010224642810

key2 是 int 类型 unique 索引，是否为 NULL 占用一个字节，那么就是 5 个字节

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

image-20231010224845992

key1 VARCHAR (100) 一个字符占 3 个字节，100 * 3，是否为 NULL 占用一个字节，varchar 的长度信息占两个字节

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

image-20231010225100396

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

image-20231010225131537

这里命中了两次联合索引，精度更高，效果更好

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

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

  • type = ref，与const（常量）比较
EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';

image-20231010225730383

  • type = eq_ref，与 atguigudb1.s1.id 比较
EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id;

image-20231010225832884

  • type = ref，与func（函数）比较
EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s2.key1 = UPPER(s1.key1);

image-20231010230024710

（9）rows ☆

预估的需要读取的记录条数，值越小越好，通常与 filtered 一起使用

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

image-20231010230159734

rows 值越小，代表数据越有可能在一个页里面，这样 IO 就会更小

（10）filtered

某个表经过搜索条件过滤后剩余记录条数与预估读取的记录条数的百分比（越大越好）

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

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

image-20231010230650764

这里就是满足 key1 > 'z' 的有 380 条，然后 AND 满足 common_field = 'a' 的只有 10%

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

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

image-20231010230926111

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

（11）Extra ☆

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

  • No tables used

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

EXPLAIN SELECT 1;

image-20231011081217425

  • Impossible WHERE

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

EXPLAIN SELECT * FROM s1 WHERE 1 != 1;

image-20231011081405880

  • Using where

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

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

image-20231011081638641

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

EXPLAIN SELECT * FROM s1 WHERE key1 = 'YHsPZz' and  common_field = 'gQMmYgKhIR';

image-20231011082053105

  • No matching min/max row

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

数据库不存在：

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

image-20231011082301800

数据库存在：

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

image-20231011082517335

  • Using index

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

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

image-20231011082723425

  • Using index condition

有些搜索条件中虽然出现了索引列，但却不能使用到索引，比如下边索引下推这个查询：

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

image-20231011082915079

  1. 这里 key1 > 'z' 走了索引，查出了380条数据
  2. key1 LIKE '%a'，这个条件依然是 key1 索引，所以接下来只要在遍历这380个索引哪些符合 '%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 INNER JOIN s2 ON s1.common_field = s2.common_field;

image-20231011083655142

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

image-20231011083827544

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

image-20231011084446231

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

  • Using temporary

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

EXPLAIN SELECT DISTINCT common_field FROM s1;

image-20231011084720910

执行计划中出现 Using temporary 并不是一个好的征兆，因为建立与维护临时表要付出很大的成本的，所以我们最好能使用索引来替代掉使用临时表，比方说下边这个包含 GROUP BY 子句的查询就不需要使用临时表：

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

image-20231011084906350

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

（12）小结

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

7. EXPLAIN 的进一步使用

7.1 EXPLAIN 四种输出格式

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

（1）传统格式

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

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

image-20231011092000954

（2）JSON格式

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

  • JSON格式：在EXPLAIN单词和真正的查询语句中间加上 FORMAT = JSON 
EXPLAIN FORMAT = JSON SELECT ....
  • EXPLAIN的Column与JSON的对应关系:(来源于MySQL 5.7文档)

image-20231011092233085

这样我们就可以得到一个json格式的执行计划，里面包含该计划花费的成本，比如这样:

EXPLAIN FORMAT=JSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a'\G
mysql> EXPLAIN FORMAT=JSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a'\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "2110.60"                               // 查询成本
    },
    "nested_loop": [
      {
        "table": {
          "table_name": "s1",
          "access_type": "ALL",                             // type
          "possible_keys": [
            "idx_key1"                                        // possible_keys
          ],
          "rows_examined_per_scan": 9595,                 // rows
          "rows_produced_per_join": 959,                  // rows * filtered
          "filtered": "10.00",                              // filtered
          "cost_info": {
            "read_cost": "959.20",
            "eval_cost": "95.95",
            "prefix_cost": "1055.15",               // 此驱动表需要花费的成本 prefix_cost = read_cost + eval_cost
            "data_read_per_join": "1M"                      // 读取数据量
          },
          "used_columns": [                                   // 要查询的字段
            "id",
            "key1",
            "key2",
            "key3",
            "key_part1",
            "key_part2",
            "key_part3",
            "common_field"
          ],
          "attached_condition": "((`atguigudb1`.`s1`.`common_field` = 'a') and (`atguigudb1`.`s1`.`key1` is not null))"
        }
      },
      {
        "table": {
          "table_name": "s2",
          "access_type": "eq_ref",
          "possible_keys": [
            "idx_key2"
          ],
          "key": "idx_key2",
          "used_key_parts": [
            "key2"
          ],
          "key_length": "5",
          "ref": [
            "atguigudb1.s1.key1"
          ],
          "rows_examined_per_scan": 1,
          "rows_produced_per_join": 959,
          "filtered": "100.00",
          "index_condition": "(cast(`atguigudb1`.`s1`.`key1` as double) = cast(`atguigudb1`.`s2`.`key2` as double))",
          "cost_info": {
            "read_cost": "959.50",
            "eval_cost": "95.95",
            "prefix_cost": "2110.60",                       // 驱动表和被驱动表的总成本 具体后面有讲
            "data_read_per_join": "1M"
          },
          "used_columns": [
            "id",
            "key1",
            "key2",
            "key3",
            "key_part1",
            "key_part2",
            "key_part3",
            "common_field"
          ]
        }
      }
    ]
  }
}
1 row in set, 2 warnings (0.01 sec)

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

"cost_info": {
    "read_cost": "959.20",
    "eval_cost": "95.95",
    "prefix_cost": "1055.15",               
    "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 表示在此次查询中需要读取的数据量

对于 s2 表的 "cost_info" 部分是这样的：

"cost_info": {
    "read_cost": "959.50",
    "eval_cost": "95.95",
    "prefix_cost": "2110.60",                       
    "data_read_per_join": "1M"
}

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

1055.15 + 959.50 + 95.95 = 2110.60

（3）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=2111 rows=960)
    -> Filter: ((s1.common_field = 'a') and (s1.key1 is not null))  (cost=1055 rows=960)
        -> Table scan on s1  (cost=1055 rows=9595)
    -> 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=1 rows=1)

1 row in set, 1 warning (0.12 sec)

（4）可视化输出

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

image-20231011101438859

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

image-20231011101551384

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

7.2 SHOW WARNINGS的使用

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

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

image-20231011101824908

使用完EXPLAIN后紧接着使用SHOW WARNINGS \G

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

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

但是大家一定要注意，我们说 Message 字段展示的信息类似于查询优化器将我们的查询语句重写后的语句，并不是等价于，也就是说 Message 字段展示的信息并不是标准的查询语句，在很多情况下并不能直接拿到黑框框中运行，它只能作为帮助我们理解 MySQL 将如何执行查询语句的一个参考依据而已

8. 分析优化器执行计划：trace

OPTIMIZER_TRACE 是MySQL 5.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> 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": 3945207,
                    "cost": 404306
                  } /* table_scan */,/*表扫描*/
                  "potential_range_indexes": [
                    {
                      "index": "PRIMARY",
                      "usable": true,
                      "key_parts": [
                        "id"
                      ] /* key_parts */
                    }
                  ] /* potential_range_indexes */,
                  "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,
                        "in_memory": 0.159895,
                        "rows": 9,
                        "cost": 1.79883,
                        "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.79883,
                    "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.69883,
                      "chosen": true
                    }
                  ] /* considered_access_paths */
                } /* best_access_path */,
                "condition_filtering_pct": 100, /*行过滤百分比*/
                "rows_for_plan": 9,
                "cost_for_plan": 2.69883,
                "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.01 sec)

9. MySQL监控分析视图-sys schema

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

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

9.2 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来完成监控、巡检等工作

🌟 如果您喜欢我的文章，欢迎赞赏支持，您的支持是我创作的最大动力！🌟
🖋 作者：Enndfp
🔗链接：https://blog.enndfp.cn
📜版权声明：您可以自由转载，但请务必注明原文地址，感谢您的尊重与支持~
MySQL

评论

  1. lzzh
    Android Chrome
    1 年前
    2023-10-13 11:04:58

    继续坚持做笔记，学习是一场马拉松，只要不放弃一定会到终点的

    • Enndfp
      博主
      lzzh
      Macintosh Safari
      1 年前
      2023-10-13 11:25:05

      通往成功的道路往往不是一帆风顺的，但只要不放弃终将会到达彼岸

发送评论 编辑评论 


				

			

						

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
							
													

					

				

			

			
			

				

					
				

			

				

											

							
							
						

																

							
							
						

																

							
							
						

										
					
											
						

	

		
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
（╯‵□′）╯︵┴─┴
￣﹃￣
(/ω＼)
∠( ᐛ 」∠)＿
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ｀)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ(￣∇￣o)
ヾ(´･ ･｀｡)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò｡)
Σ(っ °Д °;)っ
( ,,´･ω･)ﾉ"(´っω･｀｡)
╮(╯▽╰)╭
o(*////▽////*)q
＞﹏＜
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
	

	

		
颜文字
Emoji
小恐龙
花!
	


									

			

			
			
		

	






上一篇
下一篇 

                    

                    
			        推荐文章
		            

		            

							
日志

							
							

							
多版本并发控制

							
							

							
锁

							
							

							
事务

							
							

							
索引优化与查询优化

							
							

							
索引

							
							

							
存储引擎

							
							

							
逻辑架构