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. 使用到临时表，表数量较少的状况下，临时表使用缓存，可是比较大的时候，则会磁盘存储，这种状况下，性能将会急剧降低