mysql profile 详解_MySQL常用性能分析方法-profile，explain，索引

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秒。使用了二级索引稍微好点，但是效果也不好。