sql性能优化之explain续

1 possible keys 和 keys

    possible keys------>显示可能应用在这张表中的索引,一个或者多个.查询涉及到的字段上若存在索引,则该索引将被列出,但不一定被查询实际使用.

    key------>实际使用的索引,如果为NULL,则没有使用索引.查询中若使用了覆盖索引,则该索引和查询的select字段重叠(比如在  name和age 建立索引 idx_name_age ,刚好select name ,age).                         

2 key_len

    表示索引中使用的字节数,可通过该列计算查询中使用的索引长度.在不损失精确性的情况下,长度越短越好,key_len显示的值为索引字段的最大可能长度,并非实际使用长度,即key_len是根据表定义计算而得,不是通过表内计算检索出的.

  

     可以发现,where条件只有name时,key_len为25,为name和age时,为32.因为精度提高,所以索引代价也提高了.

3 ref

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

    可以看出,表t4中有组合索引idx_name_age,   test.t2.name为 test数据库的表t2的name字段,const表示常量.

当我们把表t2的name字段也添加索引,再来执行

   可以看出,ref已经变了.

   我们再来新建一个表t5,这个表和t4一模一样,当然除了表名字,这里想要测试的是当name字段在复合索引上,ref又是怎样的.

  可以看出,ref与name字段是不是复合索引无关.

4 rows

    显示表统计信息以及索引选用情况,大致估算出找到所需记录所需要读取的行数.

第一种情况,由于t5的name字段没有添加索引,所以rows较多,

 第二种情况,t2的id字段为主键,自带索引,所以rows较少.

5 extra

    包含不适合在其他列中显示但十分重要的额外信息.

    1. using filesort :说明MySQL会对数据使用一个外部的索引排序,而不是按照表内的索引顺序进行读取.MySQL中无法利用索引完成的排序成为"文件排序".

    2. using temporary :使用了临时表保存中间结果,MySQL在对查询结果排序时使用临时表,常见于排序order by和分组查询group by.

    3. using index: 表示相应的select操作中使用了覆盖索引,避免访问了表的数据行,效率不错!

                           如果同时出现 using where,表明索引被用来执行索引键值的查找.

                           如果没有同时出现using where,表明索引用来读取数据而非执行查找动作.

    4. using where : 表明使用了 where过滤.

    5.  using join buffer:  使用了连接缓存.

    7. impossible where:   where 子句的值永远是 false,不能用来获取任何元祖.

    8. distinct :优化 distinct操作,在找到第一匹配的元组后立即停止找同样值的动作.