MySQL_执行计划详细说明

 
 
 

1 简要说明

id
表格查询的顺序编号。
降序查看,id相同的从上到下查查看。
id可以为null ,当table为( union ,m,n )类型的时候,id为null,这个时候,id的顺序为 m跟n的后面。
select_type
查询的方式
下文详细说明。
table
表格名称
表名,别名,( union m,n )。
partitions
分区名称
查询使用到表分区的分区名。
type
表连接的类型
下文详细说明。
possible_keys
可能使用到的索引
这里的索引只是可能会有到,实际不一定会用到。
key
使用到的索引
实际使用的索引。
key_len
使用到索引的长度
比如多列索引,只用到最左的一列,那么使用到索引的长度则为该列的长度,故该值不一定等于 key 列索引的长度。
ref
谓词的关联信息
当 join type 为 const、eq_ref 或者 ref 时,谓词的关联信息。
可能为 :null(非 const \ eq_ref \ ref join type 时)、const(常量)、关联的谓词列名。
rows
扫描的行数
该表格扫描到的行数。这里注意在mysql里边是嵌套链接,所以,需要把所有rows相乘就会得到查询数据行关联的次数
filtered
实际显示行数占扫描rows的比例
实际显示的行数 = rows * filtered / 100
extra
特性使用
 

2 SELECT_TYPE

  1. SIMPLE,简单查询方式,不使用UNION跟子查询;
  2. PRIMARY,该表格位于最外层开始查询,通常会跟其他查询方式组合;
  3. UNION,UNION 第一个SELECT 为PRIMARY,第二个及之后的所有SELECT 为 UNION SELECT TYPE;
  4. UNION RESULT,每个结果集的取出来后,会做合并操作,这个操作就是 UNION RESULT;
  5. DEPENDENT UNION,子查询中的UNION操作,从UNION 第二个及之后的所有SELECT语句的SELECT TYPE为 DEPENDENT UNION,这个一般跟DEPENDENT SUBQUERY一起结合应用,子查询中UNION 的第一个为DEPENDENT SUBQUERY;
  6. DEPENDENT SUBQUERY,子查询中内层的第一个SELECT,依赖于外部查询的结果集;
  7. SUBQUERY,子查询内层查询的第一个SELECT,结果不依赖于外部查询结果集(不会被数据库引擎改写的情况);
  8. DERIVED,查询使用内联视图;
  9. MATERIALIZED,子查询物化,表出现在非相关子查询中 并且需要进行物化时会出现MATERIALIZED关键词;
  10. UNCACHEABLE SUBQUERY,结果集无法缓存的子查询,需要逐次查询;
  11. UNCACHEABLE UNION,表示子查询不可被物化 需要逐次运行。

2 TYPE

      性能排序:null->system->const->eq-ref->ref->fulltext->ref_or_null->index_merge->unique_subquery->index_subquery->range->index->ALL
  1. null,不访问任何一个表格
  2. system
    • 官网解释:The table has only one row (= system table). This is a special case of the const join type.
    • join type 为const,并且表格仅含有1行记录。
  3. const
    • 主键或者唯一索引的常量查询,表格最多只有1行记录符合查询,通常const使用到主键或者唯一索引进行定值查询。
    • 常量查询非常快。
  4. eq_ref
    • join 查询过程中,关联条件为主键或者唯一索引,出来的行数不止一行
    • eq_ref是一种性能非常好的 join 操作。
    • 例子说明:首先从su表格查询所有数据共7行出来,然后每一行跟 xin 的主键id中的1行做匹配。
  5. ref
    • 非聚集索引的常量查询
    • 性能也是很不错的。
  6. fulltext
    • 查询的过程中,使用到了 fulltext 索引(fulltext index在innodb引擎中,只有5.6版本之后的支持)
    • 例子是innodb引擎下、带fulltext index的表格查询
  7. ref_or_null
    • 跟ref查询类似,在ref的查询基础上,不过会加多一个null值的条件查询
  8. index merg
    • 当条件谓词使用到多个索引的最左边列并且谓词之间的连接为or的情况下,会使用到 索引联合查询
  9. unique subquery
    • eq_ref的一个分支,查询主键的子查询:
    • value IN (SELECT primary_key FROM single_table WHERE some_expr)
    • 暂时无法模拟出来,目前在5.7.17版本怎么测试,出来的type都是 eq_ref
  10. index subquery
    • ref的一个分支,查询非聚集索引的子查询:
    • value IN (SELECT key_column FROM single_table WHERE some_expr)
    • 暂时无法模拟出来,目前在5.7.17版本怎么测试,出来的type都是 ref
  11. range
    • 当谓词使用到索引范围查询的时候:=、<>、>、>=、<、<=、IS NULL、BETWEEN、IN、<=> (这是个表达式:左边可以推出右边,右边也可推出左边)
  12. index
    • 使用到索引,但是不是索引查找,而是对索引树做一个扫描,即使是索引扫描,大多数情况下也是比全表扫描性能要好的,因为索引树上的键值只有索引列键值+主键,而全表扫描则是在 聚集索引树(主键+所有列)上进行扫描,索引树相比之下要廋得多跟小得多了。
  13. all
    • 全表扫描,性能比较差。
    • 关于 index跟all,这里再举一个例子说明下
      • 下图中,表格su有3个索引:主键、ix_age、ix_name,这三个索引树的内容分别为:主键id+所有列、age+主键id、name+主键id,依次,当扫描主键id查询的时候,这三个索引都能够提供 主键id列,那么哪个性能比较好呢?索引树最小的,扫描次数最少的则为最优,根据索引数内容可得大小:ix_age < ix_name < pk,故执行计划会选择 ix_age。

3 ref

      当 join type 为 eq_ref 或者 ref 时,谓词的关联信息。可能为 :null(非 eq_ref\ref join type时)、const(常量)、关联的谓词列名。
 
 

4 extra    

  • 常用到
    1. Using index,使用到索引
    2. Using index conditio,使用到索引过滤
    3. Using MRR,使用到索引内部排序
    4. Using where,使用到where条件
    5. Using temporary,使用到临时表
  1. Using index
    • 索引覆盖,也就是不止要使用到索引,而且没有回表查询
    • 举个例子说明
    • 这两个查询中,条件都是一样,但是第一个返回的是所有列,而索引 IX_age上仅包含主键列跟索引键值,故需要再根据主键的值去PK树上找到对应的列,这个操作称为回表,所以第一个查询中extra没有USING INDEX,而第二个查询有。
  2. Using index conditio,简称 ICP
  3. Using MRR,简称 MRR
  4. Using where
    • 根据where条件,先取出数据,再跟其他表格关联查询
  5. Using filesort,无法利用索引来完成的排序
  6. Using temporary,使用到临时表
  7. 使用到临时表,表数量较少的情况下,临时表使用缓存,但是比较大的时候,则会磁盘存储,这种情况下,性能将会急剧下降
 
 
 
posted @ 2018-01-16 11:19 苏家小萝卜 阅读(...) 评论(...) 编辑 收藏
levels of contents