MySQL优化常见Extra分析——慢查询优化

数据准备：

create table user ( id int primary key, name varchar(20), sex varchar(5), index(name) )engine=innodb;

数听说明：
用户表：id主键索引，name普通索引（非惟一），sex无索引；
四行记录：其中name普通索引存在重复记录lisi；

1、【Using where】

实验语句：
explain select * from user where sex='no';

结果说明：
Extra为Using where说明，SQL使用了where条件过滤数据。

须要注意的是：
（1）返回全部记录的SQL，不使用where条件过滤数据，大几率不符合预期，对于这类SQL每每须要进行优化；
（2）使用了where条件的SQL，并不表明不须要优化，每每须要配合explain结果中的type（链接类型）来综合判断；

本例虽然Extra字段说明使用了where条件过滤，但type属性是ALL，表示须要扫描所有数据，仍有优化空间。

常见的优化方法为，在where过滤属性上添加索引。

画外音：本例中，sex字段区分度不高，添加索引对性能提高有限。

2、【Using index】

实验语句：
explain select id,name from user where name='shenjian';

结果说明：
Extra为Using index说明，SQL所须要返回的全部列数据均在一棵索引树上，而无需访问实际的行记录。

这类SQL语句每每性能较好。

问题来了，什么样的列数据，会包含在索引树上呢？

3、【Using index condition】

实验语句：
explain select id,name,sex from user
where name='shenjian';

画外音：该SQL语句与上一个SQL语句不一样的地方在于，被查询的列，多了一个sex字段。

结果说明：
Extra为Using index condition说明，确实命中了索引，但不是全部的列数据都在索引树上，还须要访问实际的行记录。

这类SQL语句性能也较高，但不如Using index。

问题来了，如何优化为Using index呢？

4、【Using filesort】

实验语句：
explain select * from user order by sex;

结果说明：
Extra为Using filesort说明，获得所需结果集，须要对全部记录进行文件排序。

这类SQL语句性能极差，须要进行优化。

典型的，在一个没有创建索引的列上进行了order by，就会触发filesort，常见的优化方案是，在order by的列上添加索引，避免每次查询都全量排序。

5、【Using temporary】

实验语句：
explain select * from user group by name order by sex;

结果说明：
Extra为Using temporary说明，须要创建临时表(temporary table)来暂存中间结果。

这类SQL语句性能较低，每每也须要进行优化。

典型的，group by和order by同时存在，且做用于不一样的字段时，就会创建临时表，以便计算出最终的结果集。

6、【Using join buffer (Block Nested Loop)】

实验语句：
explain select * from user where id in (select id from user where sex='no');

结果说明：
Extra为Using join buffer (Block Nested Loop)说明，须要进行嵌套循环计算。

画外音：内层和外层的type均为ALL，rows均为4，须要循环进行4*4次计算。

这类SQL语句性能每每也较低，须要进行优化。

典型的，两个关联表join，关联字段均未创建索引，就会出现这种状况。常见的优化方案是，在关联字段上添加索引，避免每次嵌套循环计算。

结尾：
explain是SQL优化中最经常使用的工具，搞定type和Extra，explain也就基本搞定了。