网站建设需要多久才能学会,wordpress用户角色的区别,军事热点事件2022,系统网站建设需求分析第09章_性能分析工具的使用
在数据库调优中#xff0c;我们的目标是 响应时间更快, 吞吐量更大 。利用宏观的监控工具和微观的日志分析可以帮我们快速找到调优的思路和方式。
1. 数据库服务器的优化步骤
当我们遇到数据库调优问题的时候#xff0c;该如何思考呢#xff1…第09章_性能分析工具的使用
在数据库调优中我们的目标是 响应时间更快, 吞吐量更大 。利用宏观的监控工具和微观的日志分析可以帮我们快速找到调优的思路和方式。
1. 数据库服务器的优化步骤
当我们遇到数据库调优问题的时候该如何思考呢这里把思考的流程整理成下面这张图。
整个流程划分成了 观察Show status 和 行动Action 两个部分。字母 S 的部分代表观察会使 用相应的分析工具字母 A 代表的部分是行动对应分析可以采取的行动。 我们可以通过观察了解数据库整体的运行状态通过性能分析工具可以让我们了解执行慢的SQL都有哪些查看具体的SQL执行计划甚至是SQL执行中的每一步的成本代价这样才能定位问题所在找到了问题再采取相应的行动。
详细解释一下这张图
2. 查看系统性能参数
在MySQL中可以使用 SHOW STATUS 语句查询一些MySQL数据库服务器的性能参数、执行频率。
SHOW STATUS语句语法如下
SHOW [GLOBAL|SESSION] STATUS LIKE 参数;一些常用的性能参数如下
Connections连接MySQL服务器的次数。UptimeMySQL服务器的上线时间。Slow_queries慢查询的次数。Innodb_rows_readSelect查询返回的行数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 语句所需要读取的读页的数量。
我们依然使用第8章的 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)
) ENGINEINNODB AUTO_INCREMENT1 DEFAULT CHARSETutf8;如果我们想要查询 id900001 的记录然后看下查询成本我们可以直接在聚簇索引上进行查找
SELECT student_id, class_id, NAME, create_time FROM student_info WHERE id 900001;运行结果1 条记录运行时间为 0.042s
然后再看下查询优化器的成本实际上我们只需要检索一个页即可
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.046s
然后再看下查询优化器的成本这时我们大概需要进行 20 个页的查询。
mysql SHOW STATUS LIKE last_query_cost;
----------------------------
| Variable_name | Value |
----------------------------
| Last_query_cost | 21.134453 |
----------------------------你能看到页的数量是刚才的 20 倍但是查询的效率并没有明显的变化实际上这两个 SQL 查询的时间 基本上一样就是因为采用了顺序读取的方式将页面一次性加载到缓冲池中然后再进行查找。虽然 页 数量last_query_cost增加了不少 但是通过缓冲池的机制并 没有增加多少查询时间 。
使用场景它对于比较开销是非常有用的特别是我们有好几种查询方式可选的时候。 SQL查询时一个动态的过程从页加载的角度来看我们可以得到以下两点结论 位置决定效率。如果页就在数据库 缓冲池 中那么效率是最高的否则还需要从 内存 或者 磁盘 中进行读取当然针对单个页的读取来说如果页存在于内存中会比在磁盘中读取效率高很多。批量决定效率。如果我们从磁盘中对单一页进行随机读那么效率是很低的(差不多10ms)而采用顺序读取的方式批量对页进行读取平均一页的读取效率就会提升很多甚至要快于单个页面在内存中的随机读取。 所以说遇到I/O并不用担心方法找对了效率还是很高的。我们首先要考虑数据存放的位置如果是进程使用的数据就要尽量放到缓冲池中其次我们可以充分利用磁盘的吞吐能力一次性批量读取数据这样单个页的读取效率也就得到了提升。 4. 定位执行慢的 SQL慢查询日志 4.1 开启慢查询日志参数
1. 开启 slow_query_log
在使用前我们需要先查下慢查询是否已经开启使用下面这条命令即可
mysql show variables like %slow_query_log;我们可以看到 slow_query_logOFF我们可以把慢查询日志打开注意设置变量值的时候需要使用 global否则会报错
mysql set global slow_query_logON;然后我们再来查看下慢查询日志是否开启以及慢查询日志文件的位置 你能看到这时慢查询分析已经开启同时文件保存在 /var/lib/mysql/atguigu02-slow.log 文件 中。
2. 修改 long_query_time 阈值
接下来我们来看下慢查询的时间阈值设置使用如下命令
mysql show variables like %long_query_time%;这里如果我们想把时间缩短比如设置为 1 秒可以这样设置
#测试发现设置global的方式对当前session的long_query_time失效。对新连接的客户端有效。所以可以一并
执行下述语句
mysql set global long_query_time 1;
mysql show global variables like %long_query_time%;mysql set long_query_time1;
mysql show variables like %long_query_time%;补充配置文件中一并设置参数
如下的方式相较于前面的命令行方式可以看做是永久设置的方式。
修改 my.cnf 文件[mysqld] 下增加或修改参数 long_query_time、slow_query_log 和 slow_query_log_file 后然后重启 MySQL 服务器。
[mysqld]
slow_query_logON # 开启慢查询日志开关
slow_query_log_file/var/lib/mysql/atguigu-low.log # 慢查询日志的目录和文件名信息
long_query_time3 # 设置慢查询的阈值为3秒超出此设定值的SQL即被记录到慢查询日志
log_outputFILE如果不指定存储路径慢查询日志默认存储到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)
) ENGINEINNODB AUTO_INCREMENT1 DEFAULT CHARSETutf8;步骤2设置参数 log_bin_trust_function_creators
创建函数假如报错
This function has none of DETERMINISTIC......命令开启允许创建函数设置
set global log_bin_trust_function_creators1; # 不加global只是当前窗口有效。步骤3创建函数
随机产生字符串同上一章
DELIMITER //
CREATE FUNCTION rand_string(n INT)RETURNS VARCHAR(255) #该函数会返回一个字符串
BEGINDECLARE chars_str VARCHAR(100) DEFAULT
abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ;DECLARE return_str VARCHAR(255) DEFAULT ;DECLARE i INT DEFAULT 0;WHILE i n DOSET return_str CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1RAND()*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)
BEGINDECLARE i INT DEFAULT 0;SET i FLOOR(from_num RAND()*(to_num - from_num1)) ;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((STARTi),rand_string(6),rand_num(10,100),rand_num(10,1000));UNTIL i max_numEND 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 |
-----------------------------------------
| 3523633 | 3455655 | oQmLUr | 19 | 39 |
-----------------------------------------
1 row in set (2.09 sec)mysql SELECT * FROM student WHERE name oQmLUr;
-----------------------------------------
| id | stuno | name | age | classId |
-----------------------------------------
| 1154002 | 1243200 | OQMlUR | 266 | 28 |
| 1405708 | 1437740 | OQMlUR | 245 | 439 |
| 1748070 | 1680092 | OQMlUR | 240 | 414 |
| 2119892 | 2051914 | oQmLUr | 17 | 32 |
| 2893154 | 2825176 | OQMlUR | 245 | 435 |
| 3523633 | 3455655 | oQmLUr | 19 | 39 |
-----------------------------------------
6 rows in set (2.39 sec)从上面的结果可以看出来查询学生编号为“3455655”的学生信息花费时间为2.09秒。查询学生姓名为 “oQmLUr”的学生信息花费时间为2.39秒。已经达到了秒的数量级说明目前查询效率是比较低的下面 的小节我们分析一下原因。
2. 分析
show status like slow_queries;4.5 慢查询日志分析工具mysqldumpslow
在生产环境中如果要手工分析日志查找、分析SQL显然是个体力活MySQL提供了日志分析工具 mysqldumpslow 。
查看mysqldumpslow的帮助信息
mysqldumpslow --helpmysqldumpslow 命令的具体参数如下
-a: 不将数字抽象成N字符串抽象成S-s: 是表示按照何种方式排序 c: 访问次数l: 锁定时间r: 返回记录t: 查询时间al:平均锁定时间ar:平均返回记录数at:平均查询时间 默认方式ac:平均查询次数 -t: 即为返回前面多少条的数据-g: 后边搭配一个正则匹配模式大小写不敏感的
举例我们想要按照查询时间排序查看前五条 SQL 语句这样写即可
mysqldumpslow -s t -t 5 /var/lib/mysql/atguigu01-slow.log[rootbogon ~]# mysqldumpslow -s t -t 5 /var/lib/mysql/atguigu01-slow.logReading mysql slow query log from /var/lib/mysql/atguigu01-slow.log
Count: 1 Time2.39s (2s) Lock0.00s (0s) Rows13.0 (13), root[root]localhost
SELECT * FROM student WHERE name SCount: 1 Time2.09s (2s) Lock0.00s (0s) Rows2.0 (2), root[root]localhost
SELECT * FROM student WHERE stuno NDied at /usr/bin/mysqldumpslow line 162, chunk 2.工作常用参考
#得到返回记录集最多的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 | more4.6 关闭慢查询日志
MySQL服务器停止慢查询日志功能有两种方法
方式1永久性方式
[mysqld]
slow_query_logOFF或者把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_logoff;2重启MySQL服务使用SHOW语句查询慢查询日志功能信息具体SQL语句如下。
SHOW VARIABLES LIKE %slow%;
#以及
SHOW VARIABLES LIKE %long_query_time%;4.7 删除慢查询日志
使用SHOW语句显示慢查询日志信息具体SQL语句如下。
SHOW VARIABLES LIKE slow_query_log%;从执行结果可以看出慢查询日志的目录默认为MySQL的数据目录在该目录下 手动删除慢查询日志文件 即可。
使用命令 mysqladmin flush-logs 来重新生成查询日志文件具体命令如下执行完毕会在数据目录下重新生成慢查询日志文件。
mysqladmin -uroot -p flush-logs slow提示 慢查询日志都是使用mysqladmin flush-logs命令来删除重建的。使用时一定要注意一旦执行了这个命令慢查询日志都只存在新的日志文件中如果需要旧的查询日志就必须事先备份。 5. 查看 SQL 执行成本SHOW PROFILE
show profile 在《逻辑架构》章节中讲过这里作为复习。
show profile 是 MySQL 提供的可以用来分析当前会话中 SQL 都做了什么、执行的资源消耗工具的情况可用于 sql 调优的测量。默认情况下处于关闭状态并保存最近15次的运行结果。
我们可以在会话级别开启这个功能。
mysql show variables like profiling;通过设置 profiling‘ON’ 来开启 show profile:
mysql set profiling ON;然后执行相关的查询语句。接着看下当前会话都有哪些 profiles使用下面这条命令
mysql show profiles;你能看到当前会话一共有 2 个查询。如果我们想要查看最近一次查询的开销可以使用
mysql show profile;mysql show profile cpu,block io for query 2show profile的常用查询参数
① ALL显示所有的开销信息。
② BLOCK IO显示块IO开销。
③ CONTEXT SWITCHES上下文切换开销。
④ CPU显示CPU开销信息。
⑤ IPC显示发送和接收开销信息。
⑥ MEMORY显示内存开销信 息。
⑦ PAGE FAULTS显示页面错误开销信息。
⑧ SOURCE显示和Source_functionSource_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 数据表进行查看。
6. 分析查询语句EXPLAIN
6.1 概述 1. 能做什么
表的读取顺序数据读取操作的操作类型哪些索引可以使用哪些索引被实际使用表之间的引用每张表有多少行被优化器查询
2. 官网介绍
https://dev.mysql.com/doc/refman/5.7/en/explain-output.html
https://dev.mysql.com/doc/refman/8.0/en/explain-output.html 3. 版本情况
MySQL 5.6.3以前只能 EXPLAIN SELECT MYSQL 5.6.3以后就可以 EXPLAIN SELECTUPDATE 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 就像这样
mysql EXPLAIN SELECT 1;EXPLAIN 语句输出的各个列的作用如下 在这里把它们都列出来知识为了描述一个轮廓让大家有一个大致的印象。
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)
) ENGINEINNODB CHARSETutf8;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)
) ENGINEINNODB CHARSETutf8;2. 设置参数 log_bin_trust_function_creators
创建函数假如报错需开启如下命令允许创建函数设置
set global log_bin_trust_function_creators1; # 不加global只是当前窗口有效。3. 创建函数
DELIMITER //
CREATE FUNCTION rand_string1(n INT)RETURNS VARCHAR(255) #该函数会返回一个字符串
BEGINDECLARE chars_str VARCHAR(100) DEFAULT
abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ;DECLARE return_str VARCHAR(255) DEFAULT ;DECLARE i INT DEFAULT 0;WHILE i n DOSET return_str CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1RAND()*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))
BEGINDECLARE i INT DEFAULT 0;SET autocommit 0;REPEATSET 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_numEND REPEAT;COMMIT;
END //
DELIMITER ;创建往s2表中插入数据的存储过程
DELIMITER //
CREATE PROCEDURE insert_s2 (IN min_num INT (10),IN max_num INT (10))
BEGINDECLARE i INT DEFAULT 0;SET autocommit 0;REPEATSET 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_numEND REPEAT;COMMIT;
END //
DELIMITER ;5. 调用存储过程
s1表数据的添加加入1万条记录
CALL insert_s1(10001,10000);s2表数据的添加加入1万条记录
CALL insert_s2(10001,10000);6.4 EXPLAIN各列作用
为了让大家有比较好的体验我们调整了下 EXPLAIN 输出列的顺序。
1. table
不论我们的查询语句有多复杂里边儿 包含了多少个表 到最后也是需要对每个表进行 单表访问 的所 以MySQL规定EXPLAIN语句输出的每条记录都对应着某个单表的访问方法该条记录的table列代表着该 表的表名有时不是真实的表名字可能是简称。
mysql EXPLAIN SELECT * FROM s1;这个查询语句只涉及对s1表的单表查询所以 EXPLAIN 输出中只有一条记录其中的table列的值为s1表明这条记录是用来说明对s1表的单表访问方法的。
下边我们看一个连接查询的执行计划
mysql EXPLAIN SELECT * FROM s1 INNER JOIN s2;可以看出这个连接查询的执行计划中有两条记录这两条记录的table列分别是s1和s2这两条记录用来分别说明对s1表和s2表的访问方法是什么。
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关键字
mysql EXPLAIN SELECT * FROM s1 WHERE key1 a;对于连接查询来说一个SELECT关键字后边的FROM字句中可以跟随多个表所以在连接查询的执行计划中每个表都会对应一条记录但是这些记录的id值都是相同的比如
mysql EXPLAIN SELECT * FROM s1 INNER JOIN s2;可以看到上述连接查询中参与连接的s1和s2表分别对应一条记录但是这两条记录对应的id都是1。这里需要大家记住的是在连接查询的执行计划中每个表都会对应一条记录这些记录的id列的值是相同的出现在前边的表表示驱动表出现在后面的表表示被驱动表。所以从上边的EXPLAIN输出中我们可以看到查询优化器准备让s1表作为驱动表让s2表作为被驱动表来执行查询。
对于包含子查询的查询语句来说就可能涉及多个SELECT关键字所以在**包含子查询的查询语句的执行计划中每个SELECT关键字都会对应一个唯一的id值比如这样
mysql EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 a;# 查询优化器可能对涉及子查询的查询语句进行重写转变为多表查询的操作。
mysql EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field a);可以看到虽然我们的查询语句是一个子查询但是执行计划中s1和s2表对应的记录的id值全部是1这就表明查询优化器将子查询转换为了连接查询。
对于包含UNION子句的查询语句来说每个SELECT关键字对应一个id值也是没错的不过还是有点儿特别的东西比方说下边的查询
# Union去重
mysql EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;mysql EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2;小结:
id如果相同可以认为是一组从上往下顺序执行在所有组中id值越大优先级越高越先执行关注点id号每个号码表示一趟独立的查询, 一个sql的查询趟数越少越好
3. select_type 具体分析如下 SIMPLE 查询语句中不包含UNION或者子查询的查询都算作是SIMPLE类型比方说下边这个单表查询select_type的值就是SIMPLE: mysql EXPLAIN SELECT * FROM s1; 当然连接查询也算是 SIMPLE 类型比如
mysql EXPLAIN SELECT * FROM s1 INNER JOIN s2;PRIMARY 对于包含UNION、UNION ALL或者子查询的大查询来说它是由几个小查询组成的其中最左边的那个查询的select_type的值就是PRIMARY,比方说 mysql EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;从结果中可以看到最左边的小查询SELECT * FROM s1对应的是执行计划中的第一条记录它的select_type的值就是PRIMARY。 UNION 对于包含UNION或者UNION ALL的大查询来说它是由几个小查询组成的其中除了最左边的那个小查询意外其余的小查询的select_type值就是UNION可以对比上一个例子的效果。 UNION RESULT MySQL 选择使用临时表来完成UNION查询的去重工作针对该临时表的查询的select_type就是UNION RESULT, 例子上边有。 SUBQUERY 如果包含子查询的查询语句不能够转为对应的semi-join的形式并且该子查询是不相关子查询并且查询优化器决定采用将该子查询物化的方案来执行该子查询时该子查询的第一个SELECT关键字代表的那个查询的select_type就是SUBQUERY比如下边这个查询 mysql EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 a;DEPENDENT SUBQUERY mysql EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2 WHERE s1.key2 s2.key2) OR key3 a;DEPENDENT UNION mysql EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2 WHERE key1 a UNION SELECT key1 FROM s1 WHERE key1 b);DERIVED mysql EXPLAIN SELECT * FROM (SELECT key1, count(*) as c FROM s1 GROUP BY key1) AS derived_s1 where c 1;从执行计划中可以看出id为2的记录就代表子查询的执行方式它的select_type是DERIVED, 说明该子查询是以物化的方式执行的。id为1的记录代表外层查询大家注意看它的table列显示的是derived2表示该查询时针对将派生表物化之后的表进行查询的。 MATERIALIZED 当查询优化器在执行包含子查询的语句时选择将子查询物化之后的外层查询进行连接查询时该子查询对应的select_type属性就是DERIVED比如下边这个查询 mysql 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如果想详细了解可以如下方式测试。创建分区表
-- 创建分区表
-- 按照id分区id100 p0分区其他p1分区
CREATE TABLE user_partitions (id INT auto_increment,
NAME VARCHAR(12),PRIMARY KEY(id))
PARTITION BY RANGE(id)(
PARTITION p0 VALUES less than(100),
PARTITION p1 VALUES less than MAXVALUE
);DESC SELECT * FROM user_partitions WHERE id200;查询id大于200200100p1分区的记录查看执行计划partitions是p1符合我们的分区规则
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表并为其插入一条记录 mysql CREATE TABLE t(i int) EngineMyISAM;
Query OK, 0 rows affected (0.05 sec)mysql INSERT INTO t VALUES(1);
Query OK, 1 row affected (0.01 sec)然后我们看一下查询这个表的执行计划 mysql EXPLAIN SELECT * FROM t;可以看到type列的值就是system了 测试可以把表改成使用InnoDB存储引擎试试看执行计划的type列是什么。ALL const 当我们根据主键或者唯一二级索引列与常数进行等值匹配时对单表的访问方法就是const, 比如 mysql EXPLAIN SELECT * FROM s1 WHERE id 10005;eq_ref 在连接查询时如果被驱动表是通过主键或者唯一二级索引列等值匹配的方式进行访问的如果该主键或者唯一二级索引是联合索引的话所有的索引列都必须进行等值比较。则对该被驱动表的访问方法就是eq_ref比方说 mysql EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id s2.id;从执行计划的结果中可以看出MySQL打算将s2作为驱动表s1作为被驱动表重点关注s1的访问 方法是 eq_ref 表明在访问s1表的时候可以 通过主键的等值匹配 来进行访问。 ref 当通过普通的二级索引列与常量进行等值匹配时来查询某个表那么对该表的访问方法就可能是ref比方说下边这个查询 mysql EXPLAIN SELECT * FROM s1 WHERE key1 a;fulltext 全文索引 ref_or_null 当对普通二级索引进行等值匹配查询该索引列的值也可以是NULL值时那么对该表的访问方法就可能是ref_or_null比如说 mysql EXPLAIN SELECT * FROM s1 WHERE key1 a OR key1 IS NULL;index_merge 一般情况下对于某个表的查询只能使用到一个索引但单表访问方法时在某些场景下可以使用Interseation、union、Sort-Union这三种索引合并的方式来执行查询。我们看一下执行计划中是怎么体现MySQL使用索引合并的方式来对某个表执行查询的 mysql EXPLAIN SELECT * FROM s1 WHERE key1 a OR key3 a;从执行计划的 type 列的值是 index_merge 就可以看出MySQL 打算使用索引合并的方式来执行 对 s1 表的查询。 unique_subquery 类似于两表连接中被驱动表的eq_ref访问方法unique_subquery是针对在一些包含IN子查询的查询语句中如果查询优化器决定将IN子查询转换为EXISTS子查询而且子查询可以使用到主键进行等值匹配的话那么该子查询执行计划的type列的值就是unique_subquery比如下边的这个查询语句 mysql 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 类似只不过访问子查询中的表时使用的是普通的索引比如这样 mysql EXPLAIN SELECT * FROM s1 WHERE common_field IN (SELECT key3 FROM s2 where s1.key1 s2.key1) OR key3 a;range mysql EXPLAIN SELECT * FROM s1 WHERE key1 IN (a, b, c);或者 mysql EXPLAIN SELECT * FROM s1 WHERE key1 a AND key1 b;index 当我们可以使用索引覆盖但需要扫描全部的索引记录时该表的访问方法就是index比如这样 mysql EXPLAIN SELECT key_part2 FROM s1 WHERE key_part3 a;上述查询中的所有列表中只有key_part2 一个列而且搜索条件中也只有 key_part3 一个列这两个列又恰好包含在idx_key_part这个索引中可是搜索条件key_part3不能直接使用该索引进行ref和range方式的访问只能扫描整个idx_key_part索引的记录所以查询计划的type列的值就是index。 再一次强调对于使用InnoDB存储引擎的表来说二级索引的记录只包含索引列和主键列的值而聚簇索引中包含用户定义的全部列以及一些隐藏列所以扫描二级索引的代价比直接全表扫描也就是扫描聚簇索引的代价更低一些。 ALL 最熟悉的全表扫描就不多说了直接看例子 mysql 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则没有使用索引。比方说下面这个查询
mysql 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。
7. key_len ☆
实际使用到的索引长度 (即字节数)
帮你检查是否充分的利用了索引值越大越好主要针对于联合索引有一定的参考意义。
mysql EXPLAIN SELECT * FROM s1 WHERE id 10005;int 占用 4 个字节 mysql EXPLAIN SELECT * FROM s1 WHERE key2 10126;key2上有一个唯一性约束是否为NULL占用一个字节那么就是5个字节 mysql EXPLAIN SELECT * FROM s1 WHERE key1 a;key1 VARCHAR(100) 一个字符占3个字节100*3是否为NULL占用一个字节varchar的长度信息占两个字节。 mysql EXPLAIN SELECT * FROM s1 WHERE key_part1 a;mysql EXPLAIN SELECT * FROM s1 WHERE key_part1 a AND key_part2 b;联合索引中可以比较key_len606的好于key_len303 练习
key_len的长度计算公式
varchar(10)变长字段且允许NULL 10 * ( character setutf83,gbk2,latin11)1(NULL)2(变长字段)varchar(10)变长字段且不允许NULL 10 * ( character setutf83,gbk2,latin11)2(变长字段)char(10)固定字段且允许NULL 10 * ( character setutf83,gbk2,latin11)1(NULL)char(10)固定字段且不允许NULL 10 * ( character setutf83,gbk2,latin11)8. ref mysql EXPLAIN SELECT * FROM s1 WHERE key1 a;可以看到ref列的值是const表明在使用idx_key1索引执行查询时与key1列作等值匹配的对象是一个常数当然有时候更复杂一点:
mysql EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id s2.id;mysql EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s2.key1 UPPER(s1.key1);9. rows ☆
预估的需要读取的记录条数值越小越好。
mysql EXPLAIN SELECT * FROM s1 WHERE key1 z;10. filtered
某个表经过搜索条件过滤后剩余记录条数的百分比
如果使用的是索引执行的单表扫描那么计算时需要估计出满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。
mysql EXPLAIN SELECT * FROM s1 WHERE key1 z AND common_field a;对于单表查询来说这个filtered的值没有什么意义我们更关注在连接查询中驱动表对应的执行计划记录的filtered值它决定了被驱动表要执行的次数 (即: rows * filtered)
mysql EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.key1 s2.key1 WHERE s1.common_field a;从执行计划中可以看出来查询优化器打算把s1作为驱动表s2当做被驱动表。我们可以看到驱动表s1表的执行计划的rows列为9688filtered列为10.00这意味着驱动表s1的扇出值就是9688 x 10.00% 968.8这说明还要对被驱动表执行大约968次查询。
11. Extra ☆
顾名思义Extra列是用来说明一些额外信息的包含不适合在其他列中显示但十分重要的额外信息。我们可以通过这些额外信息来更准确的理解MySQL到底将如何执行给定的查询语句。MySQL提供的额外信息有好几十个我们就不一个一个介绍了所以我们只挑选比较重要的额外信息介绍给大家。 No tables used 当查询语句没有FROM子句时将会提示该额外信息比如 mysql EXPLAIN SELECT 1;Impossible WHERE 当查询语句的WHERE子句永远为FALSE时将会提示该额外信息 mysql EXPLAIN SELECT * FROM s1 WHERE 1 ! 1;Using where mysql EXPLAIN SELECT * FROM s1 WHERE common_field a;mysql EXPLAIN SELECT * FROM s1 WHERE key1 a AND common_field a;No matching min/max row 当查询列表处有MIN或者MAX聚合函数但是并没有符合WHERE子句中的搜索条件的记录时。 mysql EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 abcdefg;Using index 当我们的查询列表以及搜索条件中只包含属于某个索引的列也就是在可以使用覆盖索引的情况下在Extra列将会提示该额外信息。比方说下边这个查询中只需要用到idx_key1而不需要回表操作: mysql EXPLAIN SELECT key1 FROM s1 WHERE key1 a;Using index condition 有些搜索条件中虽然出现了索引列但却不能使用到索引比如下边这个查询 SELECT * FROM s1 WHERE key1 z AND key1 LIKE %a;mysql EXPLAIN SELECT * FROM s1 WHERE key1 z AND key1 LIKE %b;Using join buffer (Block Nested Loop) 在连接查询执行过程中当被驱动表不能有效的利用索引加快访问速度MySQL一般会为其分配一块名叫join buffer的内存块来加快查询速度也就是我们所讲的基于块的嵌套循环算法。 mysql EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.common_field s2.common_field;Not exists 当我们使用左(外)连接时如果WHERE子句中包含要求被驱动表的某个列等于NULL值的搜索条件而且那个列是不允许存储NULL值的那么在该表的执行计划的Extra列就会提示这个信息 mysql 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索引合并的方式执行查询。 mysql EXPLAIN SELECT * FROM s1 WHERE key1 a OR key3 a;Zero limit 当我们的LIMIT子句的参数为0时表示压根儿不打算从表中读取任何记录将会提示该额外信息 mysql EXPLAIN SELECT * FROM s1 LIMIT 0;Using filesort 有一些情况下对结果集中的记录进行排序是可以使用到索引的。 mysql EXPLAIN SELECT * FROM s1 ORDER BY key1 LIMIT 10;mysql EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10;需要注意的是如果查询中需要使用filesort的方式进行排序的记录非常多那么这个过程是很耗费性能的我们最好想办法将使用文件排序的执行方式改为索引进行排序。 Using temporary mysql EXPLAIN SELECT DISTINCT common_field FROM s1;再比如 mysql EXPLAIN SELECT common_field, COUNT(*) AS amount FROM s1 GROUP BY common_field;执行计划中出现Using temporary并不是一个好的征兆因为建立与维护临时表要付出很大的成本的所以我们最好能使用索引来替代掉使用临时表比方说下边这个包含GROUP BY子句的查询就不需要使用临时表 mysql EXPLAIN SELECT key1, COUNT(*) AS amount FROM s1 GROUP BY key1;从 Extra 的 Using index 的提示里我们可以看出上述查询只需要扫描 idx_key1 索引就可以搞 定了不再需要临时表了。 其他 其它特殊情况这里省略。
12. 小结
EXPLAIN不考虑各种CacheEXPLAIN不能显示MySQL在执行查询时所作的优化工作EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况部分统计信息是估算的并非精确值
7. EXPLAIN的进一步使用
7.1 EXPLAIN四种输出格式
这里谈谈EXPLAIN的输出格式。EXPLAIN可以输出四种格式 传统格式 JSON格式 TREE格式 以及 可视化输出 。用户可以根据需要选择适用于自己的格式。
1. 传统格式
传统格式简单明了输出是一个表格形式概要说明查询计划。
mysql EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 s2.key1 WHERE s2.common_field IS NOT NULL;2. JSON格式
第1种格式中介绍的EXPLAIN语句输出中缺少了一个衡量执行好坏的重要属性 —— 成本。而JSON格式是四种格式里面输出信息最详尽的格式里面包含了执行的成本信息。
JSON格式在EXPLAIN单词和真正的查询语句中间加上 FORMATJSON 。
EXPLAIN FORMATJSON SELECT ....EXPLAIN的Column与JSON的对应关系(来源于MySQL 5.7文档)
这样我们就可以得到一个json格式的执行计划里面包含该计划花费的成本。比如这样
mysql EXPLAIN FORMATJSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 s2.key2 WHERE s1.common_field a\G我们使用 # 后边跟随注释的形式为大家解释了 EXPLAIN FORMATJSON 语句的输出内容但是大家可能 有疑问 “cost_info” 里边的成本看着怪怪的它们是怎么计算出来的先看 s1 表的 “cost_info” 部 分
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 成本 小贴士 rows和filter都是我们前边介绍执行计划的输出列在JSON格式的执行计划中rows 相当于rows_examined_per_scanfiltered名称不变。 eval_cost 是这样计算的 检测 rows × filter 条记录的成本。 prefix_cost 就是单独查询 s1 表的成本也就是 read_cost eval_cost data_read_per_join 表示在此次查询中需要读取的数据量。
对于 s2 表的 “cost_info” 部分是这样的
cost_info: {read_cost: 968.80,eval_cost: 193.76,prefix_cost: 3197.16,data_read_per_join: 1M
}由于 s2 表是被驱动表所以可能被读取多次这里的read_cost 和 eval_cost 是访问多次 s2 表后累加起来的值大家主要关注里边儿的 prefix_cost 的值代表的是整个连接查询预计的成本也就是单次查询 s1 表和多次查询 s2 表后的成本的和也就是
968.80 193.76 2034.60 3197.163. TREE格式
TREE格式是8.0.16版本之后引入的新格式主要根据查询的 各个部分之间的关系 和 各部分的执行顺序 来描述如何查询。
mysql EXPLAIN FORMATtree SELECT * FROM s1 INNER JOIN s2 ON s1.key1 s2.key2 WHERE
s1.common_field a\G
*************************** 1. row ***************************
EXPLAIN: - Nested loop inner join (cost1360.08 rows990)
- Filter: ((s1.common_field a) and (s1.key1 is not null)) (cost1013.75
rows990)
- Table scan on s1 (cost1013.75 rows9895)
- Single-row index lookup on s2 using idx_key2 (key2s1.key1), with index
condition: (cast(s1.key1 as double) cast(s2.key2 as double)) (cost0.25 rows1)
1 row in set, 1 warning (0.00 sec)4. 可视化输出
可视化输出可以通过MySQL Workbench可视化查看MySQL的执行计划。通过点击Workbench的放大镜图标即可生成可视化的查询计划。 上图按从左到右的连接顺序显示表。红色框表示 全表扫描 而绿色框表示使用 索引查找 。对于每个表 显示使用的索引。还要注意的是每个表格的框上方是每个表访问所发现的行数的估计值以及访问该表的成本。
7.2 SHOW WARNINGS的使用
在我们使用EXPLAIN语句查看了某个查询的执行计划后紧接着还可以使用SHOW WARNINGS语句查看与这个查询的执行计划有关的一些扩展信息比如这样
mysql EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 s2.key1 WHERE s2.common_field IS NOT NULL;mysql SHOW WARNINGS\G
*************************** 1. row ***************************Level: NoteCode: 1003
Message: /* select#1 */ select atguigu.s1.key1 AS key1,atguigu.s2.key1
AS key1 from atguigu.s1 join atguigu.s2 where ((atguigu.s1.key1
atguigu.s2.key1) and (atguigu.s2.common_field is not null))
1 row in set (0.00 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 SET optimizer_traceenabledon,end_markers_in_jsonon;
set optimizer_trace_max_mem_size1000000;开启后可分析如下语句
SELECTINSERTREPLACEUPDATEDELETEEXPLAINSETDECLARECASEIFRETURNCALL
测试执行如下SQL语句
select * from student where id 10;最后 查询 information_schema.optimizer_trace 就可以知道MySQL是如何执行SQL的
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 ASid,student.stuno AS stuno,student.name AS name,student.age ASage,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: 3973767,cost: 408558} /* table_scan */, //扫描表potential_range_indexes: [ //潜在的范围索引{index: PRIMARY,usable: true,key_parts: [id] /* key_parts */}] /* potential_range_indexes */,setup_range_conditions: [ //设置范围条件] /* 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,rows: 9,cost: 1.91986,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.91986,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.81986,chosen: true}] /* considered_access_paths */} /* best_access_path */,condition_filtering_pct: 100, //行过滤百分比rows_for_plan: 9,cost_for_plan: 2.81986,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.00 sec)9. MySQL监控分析视图-sys schema 9.1 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开头展示等待事件的延迟情况。
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_schemadbname;表相关
# 1. 查询表的访问量
select table_schema,table_name,sum(io_read_requestsio_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 dbdbname;语句相关
#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_tables0 or tmp_disk_tables 0
order by (tmp_tablestmp_disk_tables) desc;IO相关
#1. 查看消耗磁盘IO的文件
select file,avg_read,avg_write,avg_readavg_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;10. 小结
查询是数据库中最频繁的操作提高查询速度可以有效地提高MySQL数据库的性能。通过对查询语句的分析可以了解查询语句的执行情况找出查询语句执行的瓶颈从而优化查询语句。
