相信大部分入门数据库的朋友都是从数据库的“增删改查”学起的。其实,对于不少搞业务的非专业技术人员而言,可能基本的增删改查也够用了,由于目的并非要写的多好,只要能正确查到本身想要的分析的数据就能够了。mysql
可是,对于一个专业搞数据分析的人而言,可就没那么简单了。这个本身平时跑个小数可能也没啥感受,但现实工做中当公司业务数据量达到百万甚至千万级以上时,一个查询语句写的好坏所形成的影响就尤其明显了。因此也就不难理解为何面试的时候面试官喜欢问一些关于优化的问题。面试
为了了解本身写的SQL是好是坏,MySql提供了Explain执行计划
功能。它对优化SQL语句尤其的重要,经过它能够看清执行过程的细节,分析查询语句或是结构的性能瓶颈,找到问题所在。sql
explain
的使用很简单,就是在select 语句以前增长 explain关键字
就ok了。MySQL 会在查询上设置一个标记,执行查询时,会返回执行计划的信息,而不是执行这条SQL。好比这样:数据库
# explain + sql explain select * from table where a = 1;
能够看出执行计划给咱们提供的信息是很是有帮助的。只有读懂了这些内容,才能定位问题点在哪,进而去解决。下面东哥给你们介绍一下explain执行计划
的内容。微信
由于有些字段光看很难理解,所以创建三个表做为例子来讲明,感兴趣的朋友也能够本身跑下试试。性能
DROP TABLE IF EXISTS `actor`; CREATE TABLE `actor` ( `id` int(11) NOT NULL, `name` varchar(45) DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `actor` (`id`, `name`, `update_time`) VALUES (1,'a','2017-12-22 15:27:18'); INSERT INTO `actor` (`id`, `name`, `update_time`) VALUES (2,'b','2017-12-22 15:27:18'); INSERT INTO `actor` (`id`, `name`, `update_time`) VALUES (3,'c','2017-12-22 15:27:18');
DROP TABLE IF EXISTS `film`; CREATE TABLE `film` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `film` (`id`, `name`) VALUES (3,'film0'); INSERT INTO `film` (`id`, `name`) VALUES (1,'film1'); INSERT INTO `film` (`id`, `name`) VALUES (2,'film2');
DROP TABLE IF EXISTS `film_actor`; CREATE TABLE `film_actor` ( `id` int(11) NOT NULL, `film_id` int(11) NOT NULL, `actor_id` int(11) NOT NULL, `remark` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_film_actor_id` (`film_id`,`actor_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `film_actor` (`id`, `film_id`, `actor_id`) VALUES (1,1,1); INSERT INTO `film_actor` (`id`, `film_id`, `actor_id`) VALUES (2,1,2); INSERT INTO `film_actor` (`id`, `film_id`, `actor_id`) VALUES (3,2,1);
注意:上面三张表中,actor主键为id;film主键为id,以name字段为索引;film_actor表中id为主键,以film_id和actor_id为联合索引。优化
咱们在Navicat里随便执行一个查询语句,看看都会返回哪些内容。spa
explain select (select id from actor limit 1) from film;
执行后的结果不是查询的数据而是执行计划的解释,一共有id
,select_type
,table
,type
,possible_keys
,key
,key_len
,ref
,rows
,Extra
这些字段,每一个都表明不一样的含义,下面详细介绍。.net
id 决定了每一个表的加载和读取顺序。好比你写了个复杂的嵌套逻辑,有不少子查询,那每一个select执行的顺序就可经过id序列号观察出来。3d
原则是:id值越大越先被执行。id值相同的按从上到下的顺序执行。id为NULL的最后执行。
explain select * from film, actor, film_actor where film.id=actor.id and film.id=film_actor.id;
explain select (select id from actor limit 1) from film;
select查询的类型主要有三大类:
SIMPLE
:最简单的select查询,就是查询中不包含子查询或者union,心口如一。
explain select * from film where id=1;
PRIMARY、SUBQUERY、DERIVED 这三个是用在有嵌套逻辑的语句中的。
PRIMARY
:嵌套查询最外层的部分被标记为PRIMARY。
SUBQUERY
:出如今select或者where后面中的子查询被标记为SUBQUERY。
DERIVED
:这个其实我理解是SUBQUERY的一种特例,只不过出现的位置比较特殊,是在from后面的子查询,MySQL会将子查询结果存放在一个临时表中,称为派生表
,由于这是咱们派生出来的,而非原始表。
经过一个例子说明。
explain select (select id from actor where id = 1) from (select * from film) t;
组合类型包括UNION和UNION RESULT两个。
UNION
:UNION先后若是有两个select ,那么把出如今union以后的第二个select标记为UNION;若是UNION包含在from 子句的子查询中,外层select将被标记为DERIVED。
UNION RESULT
:从 UNION表获取结果的select。
经过一个例子说明。
explain select id from actor union all select id from actor;
表示正在访问哪一个表,以表的名称出现。
可是有两个特殊的状况:
1)当 from
子句中有子查询(派生表)时,那table就会以 < derivedN >
格式出现。由于此时查询所依赖的表是一个咱们派生出来的表,即依赖一个 id 为 N
的子查询的。好比:
explain select (select id from actor where id = 1) from (select * from film) t;
2)当使用 union
时,UNION RESULT
的 table 值为 <union1,2>
,1和2表示参与 union 的 select 行id。好比:
explain select id from actor union all select id from actor;
访问类型,表示MySQL是如何访问数据的,是全表扫描仍是经过索引等?这是考量sql查询优化中一个很重要的指标,共分有不少种类型,结果值从好到坏依次是:
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
通常来讲,好的sql查询至少达到range
级别,最好能达到ref
。下面挑几个常见且比较重要的说一下。
表里只有一行记录,这个属于const类型的特例,一行数据平时不多出现,能够忽略不计。
表示经过索引一次就找到了,const用于比较primary key 或者 unique索引。由于只需匹配一行数据,全部很快。若是将主键置于where列表中,mysql就能将该查询转换为一个const。
system
和const
有啥区别呢?看解释不太好理解,举一个例子。
explain select * from (select * from film where id = 1) tmp;
这里子查询就是const
,而最外层查询则为system
,为何呢?
由于子查询将主键id置于where中选择,咱们知道主键是有惟一性的,因此这个子查询就只返回一行记录,即匹配了一行数据。而外层查询没得选,由于子查询派生表就给了它一行数据,也就是说它要查询的表里就一行数据。所以,system是表里只有一行数据,const是从表里选出惟一一条数据,表里可能不少数据。
惟一性索引扫描,对于每一个索引键,表中只有一条记录与之匹配。常见于主键 或 惟一索引扫描。
explain select * from film_actor left join film on film_actor.film_id = film.id;
相比 eq_ref,不使用惟一索引,而是使用普通索引或者惟一性索引的部分前缀,索引要和某个值相比较,可能会找到多个符合条件的行。举例以下:
普通索引的简单查询
explain select * from film where name = "film1";
关联表查询,idx_film_actor_id
是film_id
和actor_id
的联合索引。这里使用到了film_actor的左边前缀film_id部分。
explain select film_id from film left join film_actor on film.id = film_actor.film_id;
只检索给定范围的行,使用一个索引来选择行。key列显示使用了那个索引。通常就是在where语句中出现了bettween
、<
、>
、in
等的查询。这种索引列上的范围扫描比全索引扫描要好。只须要开始于某个点,结束于另外一个点,不用扫描所有索引
explain select * from actor where id > 1;
Full Index Scan,index与ALL区别为index类型只遍历索引树。这一般比ALL快,由于索引文件一般比数据文件小。(Index与ALL虽然都是读全表,但index是从索引中读取,而ALL是从硬盘读取)
explain select * from film;
这里用了查找全部*,但也返回了index,这是由于这个表里的两个字段都是索引,id是主键,name也被定位为索引。
全表扫描,意味MySQL须要从头至尾去查找所须要的行。一般状况下这须要增长索引来进行优化了。
explain select * from film_actor;
这一列显示查询可能使用哪些索引来查找。explain 时可能出现 possible_keys 有列,而 key 显示 NULL 的状况,这种状况是由于表中数据很少,mysql认为索引对此查询帮助不大,选择了全表查询。
若是该列是NULL,则没有相关的索引。在这种状况下,能够经过检查 where 子句看是否能够创造一个适当的索引来提升查询性能,而后用 explain 查看效果。
这一列显示MySQL实际采用哪一个索引来优化对该表的访问。若是没有使用索引,则该列是 NULL。若是想强制MySQL使用或忽视possible_keys列中的索引,在查询中使用 force index、ignore index。
表示索引中使用的字节数,查询中使用的索引的长度(最大可能长度),并不是实际使用长度,理论上长度越短越好。key_len是根据表定义计算而得的,不是经过表内检索出的
举例说明:film_actor
的联合索引 idx_film_actor_id
由 film_id
和 actor_id
两个int列组成,而且每一个int是4字节。经过结果中的key_len=4
可推断出查询使用了第一个列:film_id列来执行索引查找。
explain select * from film_actor where film_id = 2;
这一列显示了在key列记录的索引中,表查找值所用到的列或常量,常见的有:const(常量),字段名。举例以下:
ref为常量
explain select * from film_actor where film_id = 2;
ref为字段
explain select film_id from film left join film_actor on film.id = film_actor.film_id;
根据表统计信息及索引选用状况,大体估算出找到所需的记录所须要读取的行数
最后一列展现额外的信息。有如下几种重要的值,Using filesort
,Using temporary
,Using index
,Using where Using index
,``
MySQL对数据使用一个外部的索引排序,而不是按照表内的索引进行排序读取。也就是说mysql没法利用索引完成的排序操做成为“文件排序” 。这种状况下通常也是要考虑使用索引来优化的。
explain select * from actor order by name;
mysql须要建立一张临时表来处理查询。出现这种状况通常是要进行优化的,首先是想到用索引来优化。常见于order by 和 group by。
举例以下:
actor.name没有索引,此时建立了张临时表。
explain select distinct name from actor;
表示相应的select操做中使用了覆盖索引
(Covering Index),避免了访问表的数据行,效率高
若是同时出现Using where
,代表索引被用来执行索引键值的查找
若是没用同时出现Using where,代表索引用来读取数据而非执行查找动做。
explain select film_id from film_actor where film_id = 1;
关于索引会专门写一篇文章介绍。
参考:
https://blog.csdn.net/belalds...
https://blog.csdn.net/UncleMo...
最后,若是喜欢本篇文章,欢迎点赞和收藏。
更多精彩内容请关注个人微信公众号:Python数据科学