MySQL性能分析之——explain的使用

1.explain+sql查看执行计划

1.使用explain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的，分析查询语句或者是性能瓶颈

2.explain+SQL语句（执行计划包含的信息）,例如我在我这个表里面建立了索引，

show index from items；

 

可以看到，我在items表的item_name和price建立了复合索引，注意，主键自带单值索引。这里看到他的索引使用了B树的数据结构。然后我们来看一下执行计划，为什么要用explain来查看执行计划，是因为我们需要知道MySQL底层有没有用到你建立的索引，执行的过程是如何的

explain select * from items；

得到如下结果：

这里有很多参数，如：

id   select_type   table  type  possible_keys   key     key_len   ref     rows    Extra

1.id:如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行

2.select_type---数据读取操作的顺序（6种） ：simple  primary   subquery  derived   union  union result

3.type(有8种值)

all  index  range  ref  eq_ref  const,system  null，

重点---->从最好到最差的依次是：system>const>eq_ref>ref>range>index>all

如上图，显示type为index。说明索引用到了，这里简单介绍一下这几个参数：

system系统-----const常量----eq_ref等值引用（主键/唯一索引，(两表)索引的所有部分都参与join且索引是主键或非空唯一键的索引）----ref引用（非唯一性索引扫描或者，返回匹配某个单独值的所有行。常见于使用非唯一索引即唯一索引的非唯一前缀进行的查找）---range范围索引（常见于between<>等查询）--index根据索引树来查，all指的是全文检索，是时间复杂度最差的查找。一般system级别的索引是达不到的，除非你达到了数据库分库分表才有可能。只要出现了const就很不错了。

4.explain之possible_key和key

possible_key:判断索引是否失效，在多个索引下MySQL到底执行了哪个索引（罗列出可能使用的索引）
key：最后被实际使用的那个key。key为null表示索引没建立或者建立没用到/失效。我在这里使用了到了items_price

5.key_len:显示的值为索引字段的最大可能长度，并非实际使用长度，越短越好

6.ref：显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或者常量被用于查找索引列上的值

7.rows:每张表有多少行被优化器查询

8.Extra：包含不适合在其他列中显示但十分重要的额外信息。会自己新建内部排序。先排序再索引，查询效率将大大提高

Extra可能会出现的三个参数：

1）using index   ：这个表示你建立的索引使用到了。如果没有和Using where同时出现，表明没有执行查找动作，而是直接从索引读取数据。我这里就是直接using index，表示我查找索引的字段的个数和顺序与我建立的索引的顺序和个数一致。
覆盖索引：查询列被索引覆盖，不再执行读取数据文件

2）using filesort  ：这个就糟糕了，你建立的索引可能用到了一部分，也可能没用到，MySQL帮你新建了内部排序（本来是要查找的）这样做非常耗性能

3）using temporary：这个就更惨了。使用了临时表保存中间结果，MySQL在对查询结果排序时会使用临时表。常见于排序order by和分组查询group by。出现这个表明MySQL帮你建立了临时表，临时表是占内存而且建立的过程是耗内存的。

好了，先说这么多。