MySQL常用性能分析方法-profile,explain,索引

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://linuxstyle.blog.csdn.net/article/details/52938346

1.查版本号

无论做什么都要确认版本号,不同的版本号下会有各种差异。

>Select  version();



2.执行状态分析

显示哪些线程正在运行

>show processlist;


下面是完整的信息



3.show profile

show profile默认的是关闭的,但是会话级别可以开启这个功能,开启它可以让MySQL收集在执行语句的时候所使用的资源。

显示数据库列表

>show databases;

切换数据库

>use test;

>SELECT @@profiling;


输出0说明profiles功能是关闭的

开启profiles功能

> set profiling=1;



需要注意为了明确看到查询性能,我们启用profiling并关闭query cache:

>SET profiling = 1;
>SET query_cache_type = 0;
>SET GLOBAL query_cache_size = 0;


执行2条SQL语句

> show profiles;



根据query_id 查看某个查询的详细时间耗费
> show profile for query 3;



ALL
显示所有性能信息

>show profile all for query 3;



ALL
显示所有性能信息
BLOCK IO
显示块IO(块的输入输出)的次数
CONTEXT SWITCHES
显示自动和被动的上下文切换数量
IPC
显示发送和接收的消息数量。
MEMORY
MySQL5.6中还未实现,只是计划实现。
SWAPS
显示swap的次数。


show profile for cpu只显示cpu信息


show profile for cpu,block io 显示cpu和io信息



参考:http://dev.mysql.com/doc/refman/5.7/en/show-profile.html

http://wing324.github.io/2016/02/02/MySQL的SHOW-PROFILE详解/?utm_source=tuicool&utm_medium=referral


4.分析执行计划和最左前缀原理

>explain + sql



关于分析结果需要注意索引有没有用到。如果显示type=ALL就是全表扫描了。

当用Explain查看SQL的执行计划时,里面有列显示了 key_len 的值,根据这个值可以判断索引的长度,在组合索引里面可以更清楚的了解到了哪部分字段使用到了索引。

如果只用到一个int那么就是4,比如上面的联合索引只用到一个就是4,用到2个就是8以此类推。

联合索引需要注意最左前缀原理,就是说匹配最左边的字段,如果你的索引使用到abc三个字段,那么查a,ab,abc都可以用到索引,查ac和bc和b和c是不行的,必须从左到右逐渐增多。

最左前缀参考:http://blog.codinglabs.org/articles/theory-of-mysql-index.html


联合索引优化策略:
如何选择索引列的顺序
1.经常会被使用到的列优先
2.选择性高的列优先
3.宽度小的列优先


如果不是int型数据,对于varchar,假如设定长度是255,由于你使用的是UTF-8字符集占3个字节,255*3+2=767,如上图所示。

具体公式如下:

key_len的长度计算公式:
varchr(10)变长字段且允许NULL    =  10 * ( character set:utf8=3,gbk=2,latin1=1)+1(NULL)+2(变长字段)
varchr(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)


关于key_len的计算参考:http://www.cnblogs.com/gomysql/p/4004244.html


explain小技巧,可以加 \G以按行来显示分析结果,避免因为按列显示不下的情况:



5.索引选择性与前缀索引

因为索引虽然加快了查询速度,但索引也是有代价的,另外,MySQL在运行时也要消耗资源维护索引,因此索引并不是越多越好。

一般两种情况下不建议建索引。
1.表记录比较少,超过2000条可以酌情考虑索引。
2.索引的选择性较低。所谓索引的选择性(Selectivity),是指不重复的索引值(也叫基数,Cardinality)与表记录数(#T)的比值:
Index Selectivity = Cardinality / #T

显然选择性的取值范围为(0, 1],选择性越高的索引价值越大,这是由B+Tree的性质决定的。

参考:http://blog.codinglabs.org/articles/theory-of-mysql-index.html


其实就是算索引的不重复度

SELECT count(DISTINCT(ID))/count(*) AS Selectivity FROM xxxx;
SELECT count(DISTINCT(xx))/count(*) AS Selectivity FROM xxxx;
SELECT count(DISTINCT(concat(xx, xxx)))/count(*) AS Selectivity FROM xxxx;
SELECT count(DISTINCT(concat(xxx, left(xx, 2))))/count(*) AS Selectivity FROM xxxx;


很明显因为主键id是不会重复的所以不重复度是100%也就是1.


6.覆盖索引

覆盖索引是指索引的叶子节点已包含所有要查询的列,因此不需要访问表数据所谓“回表”。

覆盖索引的优点
1.优化缓存,减少磁盘IO
2.减少随机IO,变随机IO为顺序IO
3.避免对Innodb主键索引的二次查询
4.避免MyISAM表进行系统调用


下面是《高性能MySQL(第3版)》中关于explain的Extra列的信息:


下面举例

第一条sql和第二条sql都是where带相同的查询条件,这个已经建了索引,但是select里第一条是都覆盖索引的,而第二条是*,自然有不覆盖的,所以需要回表

这样性能就差很多了。


再开启profile,很明显回表的要慢0.012秒,也就是12毫秒。



7.文件排序和索引排序

使用索引扫描来优化排序条件
1.索引的列顺序和Order by子句的顺序完全一致
2.索引中所有列的方向(升序,降序)和Order by子句完全一致
3.Order by中的字段全部在关联表中的第一张表中


上面是一些不同的场景,其实就是如果排序可以利用索引就可以避免文件排序。

要想知道真实的时间还是需要执行SQL,然后比较。


上图中使用主键索引id排序的查询是最快的,而使用二级索引,或者无索引的排序是非常耗时的需要10秒和17秒。使用了二级索引稍微好点,但是效果也不好。

展开阅读全文

没有更多推荐了,返回首页