• 1、id：每个SELECT都会对应一个id，就是一个复杂的SQL里可能会有很多个SELECT，也可能会包含多条执行计划，每一条执行计划都会有一个唯一的id。
• 2、select_type：就是这一条执行计划对应的查询是个什么查询类型。
• 3、table：表名，意思是要查询哪个表。
• 4、partitions：是表分区的概念。
• 5、type：针对当前这个表的访问方法，比如说const、ref、range、index、all之类的，分别代表了使用聚簇索引、二级索引、全表扫描之类的访问方式。
• 6、possible_keys：跟type结合起来的，意思就是说你type确定访问方式了，那么到底有哪些索引是可供选择，可以使用的呢，这都会放这里。
• 7、key：就是在possible_keys里实际选择的那个索引。
• 8、key_len：就是索引的长度。
• 9、ref：就是使用某个字段的索引进行等值匹配搜索的时候，跟索引列进行等值匹配的那个目标值的一些信息。
• 10、rows：是预估通过索引或者别的方式访问这个表的时候，大概可能会读取多少条数。
• 11、filtered：就是经过搜索条件过滤之后的剩余数据的百分比。
• 12、extra：是一些额外的信息。

select_type是SIMPLE表示查询类型是很普通的且简单。表名就是t1，all就是全表扫描，这没办法，你完全没加任何where条件，那当然只能是全表扫描了！这里直接会扫描表的聚簇索引的叶子节点，按顺序扫描过去拿到表里全部数据。rows是3457，这说明全表扫描会扫描这个表的3457条数据，说明这个表里就有3457条数据，此时你全表扫描会全部扫描出来。filtered是100%，你没有任何where过滤条件，所以直接筛选出来的数据就是表里数据的100%占比。

2、多表查询：

EXPLAIN SELECT * FROM t1 WHERE x1 IN (SELECT x1 FROM t2) OR x3 = 'xxxx';

• 首先，第一条执行计划的id是1，第二条执行计划的id是2，因为SQL里有两个SELECT，主查询SELECT的执行计划的id就是1，子查询SELECT的执行计划的id就是2 。
• 其次，第一条执行计划里，select_type是PRIMARY，不是SIMPLE了，主查询的意思。
• 对主查询而言，他有一个where条件是x3='xxx'，所以他的possible_keys里包含了index_x3，就是x3字段的索引，但是他的key实际是NULL，而且type是ALL，所以说他最后没选择用x3 字段的索引，而是选择了全表扫描。这是为什么呢？其实很简单，可能他通过成本分析发现，使用x3字段的索引扫描xxx这个值，几乎就跟全表扫描差不多，可能x3这个字段的值几乎都是xxx，所以最后就选择还不如直接全表扫描呢。
• 接着，第二条执行计划，他的select_type是SUBQUERY，也就是子查询，子查询针对的是t2这个表，当然子查询本身就是一个全表查询，但是对主查询而言，会使用x1 in 这个筛选条件
• type是index，说明使用了扫描index_x1这个x1字段的二级索引的方式，直接扫描x1字段的二级索引，来跟子查询的结果集做比对。

4、Union查询

EXPLAIN SELECT * FROM t1 UNION SELECT * FROM t2

union字句默认的作用是把两个结果集合并起来还会进行去重，所以第三条执行计划就是去重。

• table是<union 1,2>，这就是一个临时表的表名。
• extra里有一个using temporary，也就是使用临时表的意思，他就是把结果集放到临时表里进行去重的。
• 当然，如果你用的是union all，那么就不会进行去重了。

• id：一个SELECT子句对应一个id，如果有多个SELECT就会对应多个id。但有时候一个SELECT字句涉及多个表，所以会对应多条执行计划，此时可能多条执行计划的id一样。
• select_type：SIMPLE、primary和subquery的。
  • 一般如果单表查询或者是多表连接查询，其实他们的select_type都是SIMPLE。
  • 如果是union语句的话，就类似于select * from t1 union select * from t2，那么会对应两条执行计划，第一条执行计划是针对t1表的，select_type是PRIMARY，第二条执行计划是针对t2表的，select_type是UNION，这就是在出现union语句的时候，他们就不一样了。
  • 在使用union语句的时候，会有第三条执行计划，意思是针对两个查询的结果依托一个临时表进行去重，第三条执行计划的select_type就是union_result。
  • 如果SQL里有子查询的话，类似select * from t1 where x1 in (select x1 from t2) or x3='xxx'，此时其实会有两条执行计划，第一条执行计划的select_type是PRIMARY，第二条执行计划的select_type是SUBQUERY。

5、复杂SQL查询

EXPLAIN SELECT * FROM t1 WHERE x1 IN (SELECT x1 FROM t2 WHERE x1 = 'xxx' UNION SELECT x1 FROM t1 WHERE x1 = 'xxx');

• 第一个执行计划一看就是针对t1表查询的那个外层循环，select_type就是PRIMARY，因为这里涉及到了子查询，所以外层查询的select_type一定是PRIMARY了。
• 第二个执行计划是子查询里针对t2表的查询语句，他的select_type是dependent subquery。
• 第三个执行计划是子查询里针对t1表的另外一个查询语句，select_type是dependent union，因为第三个执行计划是在执行union后的查询。
• 第四个执行计划select_type是union result，因为在执行子查询里两个结果集的合并以及去重

6、更复杂SQL查询

explain select * from (select x1, count(*) as cnt from t1 group by x1) as _t1 where cnt > 10;

FROM子句后跟了一个子查询，在子查询里是根据x1字段进行分组然后进行count聚合操作，也就是统计出来x1这个字段每个值的个数，然后在外层则是针对这个内层查询的结果集进行查询通过where条件来进行过滤。

子查询里的那个语句的执行计划，select_type是derived，意思是针对子查询执行后的结果集会物化为一个内部临时表，然后外层查询是针对这个临时的物化表执行的。

select * fromt1 where id=110

EXPLAIN select * from t1 inner join t2 on t1.id = t2.id

• possible_keys：就是在针对一个表进行查询的时候有哪些潜在可以使用的索引。
  • 比如你有两个索引，一个是KEY(x1, x2, x3)，一个是KEY(x1, x2, x4)，此时要是在where条件里要根据x1和x2两个字段进行查询，那么此时明显是上述两个索引都可以使用的，那么到底要使用哪个呢？
  • 此时就需要通过我们之前讲解的成本优化方法，去估算使用两个索引进行查询的成本，看使用哪个索引 的成本更低，那么就选择用那个索引，最终选择的索引，就是执行计划里的key这个字段的值了。
• key_len：就是当你在key里选择使用某个索引之后，那个索引里的最大值的长度是多少，这个就是给你一个参考，大概知道那个索引里的值最大能有多长。

EXPLAIN SELECT x1 FROM t1 WHERE x1 = 'xxx'

首先他是访问了t1表，使用的是ref访问方法，也就是基于二级索引去查找，找的是index_x1这个索引，这个索引的最大数据长度是456字节，查找的目标是一个const代表的常量值，通过索引可以查出来25条数据，经过其他条件筛选过后，最终剩下数据是100%。

extra的信息：Using index是说这次查询，仅仅涉及到了一个二级索引，不需要回表，因为他仅仅是查出来了x1这个字段，直接从index_x1索引里查就行了。如果没有回表操作，仅仅在二级索引里执行，那么extra里会告诉是Using index。

SELECT * FROM t1 WHERE x1 > 'xxx' AND x1 LIKE '%xxx'

EXPLAIN SELECT * FROM t1 WHERE x2 = 'xxx'

EXPLAIN SELECT * FROM t1 WHERE x1 = 'xxx' AND x2 = 'xxx'

EXPLAIN SELECT * FROM t1 ORDER BY x1 LIMIT 10

这就是典型的一个排序后再分页的语句，他的执行计划如下

EXPLAIN SELECT * FROM t1 ORDER BY x2 LIMIT 10

EXPLAIN SELECT x2, COUNT(*) AS amount FROM t1 GROUP BY x2

这里的x2是没有索引的，所以此时的执行计划如下