mysql优化之 Explain 分析sql语句效率

内容部分转载:原文 https://www.cnblogs.com/clphp/p/5403215.html

Explain命令在解决数据库性能上是第一推荐使用命令,大部分的性能问题可以通过此命令来简单的解决,Explain可以用来查看SQL语句的执行效 果,可以帮助选择更好的索引和优化查询语句,写出更好的优化语句。

Explain语法:explain select … from … [where …]

例如:explain select  *  from  class  left join  book  on  class.card  =  book.card ;

输出:

下面对各个属性进行了解:

1、id:这是SELECT的查询序列号

id相同 :标识sql的顺序是由上到下顺序执行,如图

上面的这个sql语句通过id得知识顺序执行的,但是表的加载顺序是 t1   t3   t2   ,他的加载顺序是从where条件后面的语句反过来加载的

id不同 :如果是子查询,id值标识权重,权重越大的被先执行,如图

在上面的这个sql语句中首先加载查询的是 t3-->t1-->t2

id相同不同:这种情况下,还是权重越大的优先级越高,如图

这个sql中括号里面是查询了t3 ,所以首先加载t3,在加载where中的t2。

2、select_type:select_type就是 select的类型,可以有以下几种:

SIMPLE:简单sql(不使用UNION或子查询等)

PRIMARY:最外面的SELECT(最后加载的那个sql语句

UNION:UNION中的第二个或后面的SELECT语句

DEPENDENT UNION:UNION中的第二个或后面的SELECT语句,取决于外面的查询

UNION RESULT:UNION的结果。

SUBQUERY:子查询中的第一个SELECT

DEPENDENT SUBQUERY:子查询中的第一个SELECT,取决于外面的查询

DERIVED:导出表的SELECT(FROM子句的子查询)

3、table:显示这一行的数据是关于哪张表的

4、type:这列最重要,显示了连接使用了哪种类别,有无使用索引,是使用Explain命令分析性能瓶颈的关键项之一

结果值从好到坏依次是:

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

一般来说,得保证查询至少达到range级别,最好能达到ref,否则就可能会出现性能问题。

比如:如果明确表中只有一条数据,查询时type就是system , 如图

在子查询查询完成后返回了一个虚拟表,可以明确的是虚拟表中就只有一条数据,所以最外层sql的type是system

type的常见的值以及解释:

system:表中只有一条记录,等于系统表,是const类型的特列

const: 标识通过索引一次就定位到了数据,用于比较primary key 或者 unique 索引,因为很快,比如讲主键放入到where条件中

eq_ref:唯一索引扫描,对于每一个索引键,表中只有一条记录匹配,常见于主键扫描或唯一索引扫描

ref:非唯一性索引扫描,他可能遭到多个符合条件的行,是属于查找和扫描的混合体

range:只检索指定范围的行,通过索引来选择行,在key 列显示了使用了那个索引。

indesx:只遍历了索引数,比ALL块

all :全表扫描,百万级别的数据时,all是大忌

5、possible_keys:列指出MySQL能使用哪个索引在该表中找到行(这里一般就指的是可能被使用到的的索引

6、key:显示MySQL实际决定使用的键(索引)。如果没有选择索引,键是NULL ( 实际使用到的索引

7、key_len:显示MySQL决定使用的键长度。如果键是NULL,则长度为NULL。使用的索引的长度。在不损失精确性的情况下,长度越短越好

8、ref:显示索引的那一列被使用了,如果可能的话,最好是一个常数 const。(我这里是给book表中的card字段添加了索引)

9、rows:显示MySQL认为它执行查询时必须检查的行数【每张表有多少行被优化器查询】。(总量越小越好)

10、Extra:包含MySQL解决查询的详细信息,也是关键参考项之一

Distinct
一旦MYSQL找到了与行相联合匹配的行,就不再搜索了

Not exists
MYSQL 优化了LEFT JOIN,一旦它找到了匹配LEFT JOIN标准的行,

就不再搜索了

Range checked for each

Record(index map:#)
没有找到理想的索引,因此对于从前面表中来的每一 个行组合,MYSQL检查使用哪个索引,并用它来从表中返回行。这是使用索引的最慢的连接之一

Using filesort
看 到这个的时候,查询就需要优化了。MYSQL需要进行额外的步骤来对返回的数据进行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来 排序全部行(给指定排序的字段添加索引,可以避免文件内排序

Using index
表示对表的操作使用到了覆盖索引(查询的列和建立索引的列相同),速度非常快,列数据是从仅仅使用了索引中的信息而没有读取实际的表返回的,这发生在对表 的全部的请求列都是同一个索引的部分的时候

Using temporary
看到这个的时候,查询需要优化了。(比Using filesort更差)这 里,MYSQL需要创建一个临时表来存储结果,这通常发生在对不同的列集进行ORDER BY上,而不是GROUP BY上

Using where    一句话解释 (表明使用了where过滤)
使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行,并且连接类型ALL或index, 这就会发生,或者是查询有问题

Using join buffer :使用了链接缓存,各种join时

impossible where :where子句的值总返回false,不能够用来获取任何元组 如图

这个方式也可以用来判断where是否生效

需要注意的是

             1:索引作为一种高效的数据结构,正确的索引能够大大的提高查询的效率,在频繁的delete和update字段是不适合新建索引的,删除的时候使用软删除的形式也能够很好的避免索引不准确的问题。如图(二叉树索引)

             2:索引本身也很大:需要存放到存储设备中(磁盘)

             3:左连接查询是索引应该添加到右表,右连接查询时索引应该放到左表,(做到和连接查询相反),加入有 A  B 

两个表,DBA 只对  B 表做了索引,使用  SELECT    *   FROM   A  LEFT  JOIN  B  WHERE A.KEY = B.KEY   。这是有连接查询的特性决定的,如果使用右连接,则一定会包含坐标中的全部数据,索引没什么用(如图)

DROP INDEX  Y ON  book  删除book中的 Y 索引

猜你喜欢

转载自blog.csdn.net/m0_37852399/article/details/86666478