一、解读type
执行打算的type示意拜访数据类型，有很多种拜访类型。

1、system
示意这一步只返回一行数据，如果这一步的执行对象是一个驱动表或者主表，那么被驱动表或者子查问只是被拜访一次。

2、const

示意这个执行步骤最多只返回一行数据。const通常呈现在对主键或惟一索引的等值查问中，例如对表t主键id的查问：

3、eq_ref

eq_ref类型个别意味着在表关联时，被关联表上的关联列走的是主键或者惟一索引。例如，表jiang关联lock_test表，关联列别离是两张表的主键列 ：

下面SQL执行时，jiang表是驱动表，lock_test是被驱动表，被驱动表的关联列是主键id，type类型为eq_ref。

所以，对于eq_ref类型来说有一个重要的特点就是：这一步波及到的表是被驱动表；这一步中应用到惟一索引或主键。除了system和const之外，这是成果最好的关联类型。

4、ref

与下面相同，如果执行打算的某一步的type是ref的话，示意这一步的关联列是非惟一索引。例如，用表jiang的主键id列关联表lock_test的num列，num列上建设了一般索引：

下面SQL执行时，表jiang是驱动表，lock_test是被驱动表，被驱动表上走的是非惟一索引，type类型为ref。

所以ref的特点是：示意这一步拜访数据应用的索引是非惟一索引。

5、Ref_or_null
例如执行上面语句：

示意走了索引(num列上有索引)，然而也拜访了游戏的空值。

6、index_merge

示意索引合并，个别对多个二级索引列做or操作时就会产生索引合并。
例如执行下列语句：
mysql> explain select * from lock_test where id=3 or num=4;

id为主键，num列上建有一般索引，语句执行时，会通过两个单列索引来解决or操作。

7、unique_subquery
示意惟一子查问。例如有如下语句执行时：
value in(select primary_key from single_table where ...)
对于in子句来说，当in子句里的子查问返回的是某一个表的主键时，type显示为unique subquery。

8、index_subquery
当有如下语句执行时：
value in(select key_column from single_table where ...)
与下面的类似，示意对于in子句来说，当in子句里的子查问返回的是某一个表的二级索引列(非主键列)时，type显示为index_subquery。

9、range：
在有索引的列上取一部分数据。常见于在索引列上执行between and操作。

10、index：
索引全扫描，个别产生在笼罩索引的时候，也就是对有索引列产生一次全扫描。

11、all：
没有索引的全表扫描。
一个特例：

Explain select * from stu limit 1,1;

二、解读extra
1、using where：
个别有两层意思：
示意通过索引拜访时，须要再回表拜访所需的数据；
过滤条件产生在server层而不是存储引擎层；
如果执行打算中显示走了索引，然而rows值很高，extra显示为www.sangpi.comusing where，那么执行成果就不会很好。因为索引拜访的老本次要在回表上，这时能够采纳笼罩索引来优化。
通过笼罩索引也能将过滤条件下压，在存储引擎层执行过滤操作，这样成果是最好的。
所以，笼罩索引是解决using where的最无效的伎俩。

2、using index condition
示意将过滤下压到存储层执行，避免server层过滤过多数据
如果extra中呈现了using index condition，阐明对拜访表数据进行了优化。

3、using temporary
示意语句执行过程中应用到了长期表。以下子句的呈现可能会应用到长期表：
order by
group by
distinct
union等
数据不能间接返回给用户，就须要缓存，数据就以长期表缓存在用户工作空间。留神，可能会呈现磁盘长期表，须要关注须要缓存的数据的rows。
能够应用索引打消下面的四个操作对应的长期表。

4、using sort_union(indexs)

Sname和sphone列上都有索引，这时执行打算的extra项就会显示using sort_union(i_sname,i_spone)，示意索引合并。常随同着index_merge。

5、using MRR：
个别通过二级索引拜访表数据的过程是：先拜访二级索引列，找到对应的二级索引数据后就失去对应的主键值，而后拿着这个主键值再去拜访表，取出行数据。这样取出的数据是依照二级索引排序的。
MRR示意：通过二级索引失去对应的主键值后，不间接拜访表而是先存储起来，在失去所有的主键值后，对主键值进行排序，而后再拜访表。这样能够大幅减低对表的拜访次数，至多实现了程序拜访表。
MRR的一个长处就是晋升索引拜访表的效率，也就是升高了回表的老本。然而有一个比拟大的问题：取出来的数据就不依照二级索引排序了。

6、using join buffer(Block Nested Loop)
BNL次要产生在两个表关联时，被关联的表上没有索引。
BNL示意这样的意思：A关联B，A的关联列上有索引而B的没有。这时就会从A表中取10行数据拿进去放到用户的join buffer空间中，而后再取B上的数据和join buffer中A的关联列进行关联，这时只须要对B表拜访一次，也就是B表产生一次全表扫描。
如果join buffer中的10行数据关联完后，就再取10行数据持续和B表关联，始终到A表的所有数据都关联完为止。
从下面能够看进去，这种形式大略效率会进步约90%。

7、using join buffer(Batched Key Access)
个别呈现BKA的状况是：表关联时，被驱动表上有索引，然而驱动表返回的行数太多。
当呈现上述情况时，就会将驱动表的返回后果集放到用户工作空间的join buffer中，而后取后果集的一条记录去关联被驱动表的索引关联列。失去相应的主键列后并不马上通过这个主键列去被被驱动表中取数据，而是先寄存到工作空间中。等到后果集中的所有数据都关联完了，对工作空间中的所有通过关联失去主键列进行排序，而后对立拜访被驱动表，从中取数据。这样的益处就是大大降低了拜访的次数。
从下面能够看出：BKA用到了MRR技术；BKA适宜驱动表返回行数较多、被驱动表拜访时走的是索引的状况。
这个性能能够关上或者敞开：
Set optimizer_switch=’mrr=on,batched_key_access=on’;

8、using index for group by
示意通过复合索引实现group by,不必回表。
例如复合索引(a,b)，执行语句：select a from tb group by b;时就会呈现using index for group by。

9、using index

示意实现了笼罩索引扫描；也就是须要拜访的数据都在索引中，不须要回表。在个别状况下，缩小不必要的数据拜访可能晋升效率。

例如对表lock_test取num列上的数据，num列上建设一般索引：

10、using filesort
阐明有排序行为，然而不肯定是磁盘排序。

11、materialize scan
对物化表的全扫描，因为物化表就是一个长期表，表上没有索引。

数栈是云原生—站式数据中台PaaS，咱们在github和gitee上有一个乏味的开源我的项目：FlinkX，FlinkX是一个基于Flink的批流对立的数据同步工具，既能够采集动态的数据，也能够采集实时变动的数据，是全域、异构、批流一体的数据同步引擎。