简介

一条查询语句在经过MySQL查询优化器的各种基于成本和规则的优化会后生成一个所谓的执行计划，这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。MySQL的设计者贴心的为我们提供了EXPLAIN语句来帮助我们查看某个查询语句的具体执行计划，这篇文章是为了解EXPLAIN语句的各个输出项都是干嘛使的，从而可以有针对性的提升我们查询语句的性能。

EXPLAIN详解

查看执行计划的语法

EXPLAIN SELECT 1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | No tables used |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+

上面这些就是所谓的执行计划，我们可以在这个执行计划的辅助下，改进自己的查询语句以使查询执行起来更高效。其实除了以SELECT开头的查询语句，其余的DELETE、INSERT、REPLACE以及UPDATE语句前边都可以加上EXPLAIN

大致罗列一下EXPLAIN语句输出的各个列的作用

列名	描述
id	在一个大的查询语句中每个SELECT关键字都对应一个唯一的id
select_type	SELECT关键字对应的那个查询的类型
table	表名
partitions	匹配的分区信息
type	针对单表的访问方法
possible_keys	可能用到的索引
key	实际上使用的索引
key_len	实际使用到的索引长度
ref	当使用索引列等值查询时，与索引列进行等值匹配的对象信息
rows	预估的需要读取的记录条数
filtered	某个表经过搜索条件过滤后剩余记录条数的百分比
Extra	一些额外的信息

执行计划输出中各列详解

table

不论我们的查询语句有多复杂，里边儿包含了多少个表，到最后也是需要对每个表进行单表访问的，所以MySQL的设计者规定EXPLAIN语句输出的每条记录都对应着某个单表的访问方法，该条记录的table列代表着该表的表名。所以我们看一条比较简单的查询语句：

EXPLAIN SELECT * FROM single_table;

+----+-------------+--------------+------------+------+---------------+------+---------+------+-------+----------+-------+
| id | select_type | table        | partitions | type | possible_keys | key  | key_len | ref  | rows  | filtered | Extra |
+----+-------------+--------------+------------+------+---------------+------+---------+------+-------+----------+-------+
|  1 | SIMPLE      | single_table | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 91610 |   100.00 | NULL  |
+----+-------------+--------------+------------+------+---------------+------+---------+------+-------+----------+-------+
1 row in set, 1 warning (0.00 sec)

这个查询语句只涉及对single_table表的单表查询，所以EXPLAIN输出中只有一条记录，其中的table列的值是single_table，表明这条记录是用来说明对single_table表的单表访问方法的。

下边我们看一下一个连接查询的执行计划：

EXPLAIN SELECT * FROM t1 JOIN t2 ON t1.m1=t2.m2;

+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                      |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
|  1 | SIMPLE      | t1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |   100.00 | NULL                                       |
|  1 | SIMPLE      | t2    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where; Using join buffer (hash join) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+

可以看到这个连接查询的执行计划中有两条记录，这两条记录的table列分别是t1和t2，这两条记录用来分别说明对t1表和t2表的访问方法是什么。

id

我们知道我们写的查询语句一般都以SELECT关键字开头，比较简单的查询语句里只有一个SELECT关键字，比如下边这个查询语句：

SELECT * FROM s1 WHERE key1 = 'a';

稍微复杂一点的连接查询中也只有一个SELECT关键字，比如：

SELECT * FROM s1 INNER JOIN s2
ON s1.key1 = s2.key1
WHERE s1.common_field = 'a';

但是下边两种情况下在一条查询语句中会出现多个SELECT关键字：

查询中包含子查询的情况

比如下边这个查询语句中就包含2个SELECT关键字：

SELECT * FROM s1
WHERE key1 IN (SELECT key3 FROM s2);
查询中包含UNION语句的情况

比如下边这个查询语句中也包含2个SELECT关键字：

SELECT * FROM s1 UNION SELECT * FROM s2;

查询语句中每出现一个SELECT关键字，设计MySQL的大叔就会为它分配一个唯一的id值。这个id值就是EXPLAIN语句的第一个列，比如下边这个查询中只有一个SELECT关键字，所以EXPLAIN的结果中也就只有一条id列为1的记录：

EXPLAIN SELECT * FROM single_table WHERE key1 = 'a';

+----+-------------+--------------+------------+------+---------------+----------+---------+-------+------+----------+-------+
| id | select_type | table        | partitions | type | possible_keys | key      | key_len | ref   | rows | filtered | Extra |
+----+-------------+--------------+------------+------+---------------+----------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | single_table | NULL       | ref  | idx_key1      | idx_key1 | 303     | const |    1 |   100.00 | NULL  |
+----+-------------+--------------+------------+------+---------------+----------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

对于连接查询来说，一个SELECT关键字后边的FROM子句中可以跟随多个表，所以在连接查询的执行计划中，每个表都会对应一条记录，但是这些记录的id值都是相同的，比如：

EXPLAIN SELECT * FROM t1 JOIN t2 ON t1.m1=t2.m2;

+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                      |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
|  1 | SIMPLE      | t1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |   100.00 | NULL                                       |
|  1 | SIMPLE      | t2    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where; Using join buffer (hash join) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+

可以看到，上述连接查询中参与连接的t1和t2表分别对应一条记录，但是这两条记录对应的id值都是1。这里需要大家记住的是，在连接查询的执行计划中，每个表都会对应一条记录，这些记录的id列的值是相同的，出现在前边的表表示驱动表，出现在后边的表表示被驱动表。所以从上边的EXPLAIN输出中我们可以看出，查询优化器准备让t1表作为驱动表，让t2表作为被驱动表来执行查询。

对于包含子查询的查询语句来说，就可能涉及多个SELECT关键字，所以在包含子查询的查询语句的执行计划中，每个SELECT关键字都会对应一个唯一的id值，比如这样：

EXPLAIN SELECT * FROM t1 WHERE m1 IN (SELECT m2 FROM t2) OR n1 = 'a';

+----+--------------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type        | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+--------------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | PRIMARY            | t1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |   100.00 | Using where |
|  2 | DEPENDENT SUBQUERY | t2    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where |
+----+--------------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+

从输出结果中我们可以看到，t1表在外层查询中，外层查询有一个独立的SELECT关键字，所以第一条记录的id值就是1，t2表在子查询中，子查询有一个独立的SELECT关键字，所以第二条记录的id值就是2。

但是这里大家需要特别注意，查询优化器可能对涉及子查询的查询语句进行重写，从而转换为连接查询。所以如果我们想知道查询优化器对某个包含子查询的语句是否进行了重写，直接查看执行计划就好了，比如说：

EXPLAIN SELECT * FROM t1 WHERE m1 IN (SELECT m2 FROM t2 WHERE n2='a');

+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                                      |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------------------------------------------------+
|  1 | SIMPLE      | t1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |   100.00 | NULL                                                       |
|  1 | SIMPLE      | t2    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where; FirstMatch(t1); Using join buffer (hash join) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------------------------------------------------+

可以看到，虽然我们的查询语句是一个子查询，但是执行计划中t1和t2表对应的记录的id值全部是1，这就表明了查询优化器将子查询转换为了连接查询。

对于包含UNION子句的查询语句来说，每个SELECT关键字对应一个id值也是没错的，不过还是有点儿特别的东西，比方说下边这个查询：

EXPLAIN SELECT * FROM t1  UNION SELECT * FROM t2;

+----+--------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+
| id | select_type  | table      | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra           |
+----+--------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+
|  1 | PRIMARY      | t1         | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |   100.00 | NULL            |
|  2 | UNION        | t2         | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |   100.00 | NULL            |
| NULL | UNION RESULT | <union1,2> | NULL       | ALL  | NULL          | NULL | NULL    | NULL | NULL |     NULL | Using temporary |
+----+--------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+

这个语句的执行计划的第三条记录是个什么鬼？为毛id值是NULL，而且table列长的也怪怪的？大家别忘了UNION子句是干嘛用的，它会把多个查询的结果集合并起来并对结果集中的记录进行去重，怎么去重呢？MySQL使用的是内部的临时表。正如上边的查询计划中所示，UNION子句是为了把id为1的查询和id为2的查询的结果集合并起来并去重，所以在内部创建了一个名为<union1, 2>的临时表（就是执行计划第三条记录的table列的名称），id为NULL表明这个临时表是为了合并两个查询的结果集而创建的。

跟UNION对比起来，UNION ALL就不需要为最终的结果集进行去重，它只是单纯的把多个查询的结果集中的记录合并成一个并返回给用户，所以也就不需要使用临时表。所以在包含UNION ALL子句的查询的执行计划中，就没有那个id为NULL的记录，如下所示：

 EXPLAIN SELECT * FROM t1  UNION ALL SELECT * FROM t2;

+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | PRIMARY     | t1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |   100.00 | NULL  |
|  2 | UNION       | t2    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+

select_type

通过上边的内容我们知道，一条大的查询语句里边可以包含若干个SELECT关键字，每个SELECT关键字代表着一个小的查询语句，而每个SELECT关键字的FROM子句中都可以包含若干张表（这些表用来做连接查询），每一张表都对应着执行计划输出中的一条记录，对于在同一个SELECT关键字中的表来说，它们的id值是相同的。

MySQL的设计者为每一个SELECT关键字代表的小查询都定义了一个称之为select_type的属性，意思是我们只要知道了某个小查询的select_type属性，就知道了这个小查询在整个大查询中扮演了一个什么角色，口说无凭，我们还是先来见识见识这个select_type都能取哪些值（为了精确起见，我们直接使用文档中的英文做简要描述，随后会进行详细解释的）：

名称	描述
SIMPLE (简单查询)	Simple SELECT (not using UNION or subqueries)
PRIMARY (主要查询)	Outermost SELECT
UNION (联合查询)	Second or later SELECT statement in a UNION
UNION RESULT (联合结果查询)	Result of a UNION
SUBQUERY (子查询)	First SELECT in subquery
DEPENDENT SUBQUERY (相关子查询)	First SELECT in subquery, dependent on outer query
DEPENDENT UNION (相关联合查询)	Second or later SELECT statement in a UNION, dependent on outer query
DERIVED (派生查询)	Derived table
MATERIALIZED (物化表查询)	Materialized subquery
UNCACHEABLE SUBQUERY (当前子查询)	A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query
UNCACHEABLE UNION (当前联合查询)	The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY)

各个描述的详解：

SIMPLE

查询语句中不包含UNION或者子查询的查询都算作是SIMPLE类型，比方说下边这个单表查询的select_type的值就是SIMPLE：

	EXPLAIN SELECT * FROM single_table;

	+----+-------------+--------------+------------+------+---------------+------+---------+------+-------+----------+-------+
	| id | select_type | table        | partitions | type | possible_keys | key  | key_len | ref  | rows  | filtered | Extra |
	+----+-------------+--------------+------------+------+---------------+------+---------+------+-------+----------+-------+
	|  1 | SIMPLE      | single_table | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 91610 |   100.00 | NULL  |
	+----+-------------+--------------+------------+------+---------------+------+---------+------+-------+----------+-------+

当然，连接查询也算是SIMPLE类型，比如：

	EXPLAIN SELECT * FROM t1 JOIN t2 ON t1.m1=t2.m2;

	+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
	| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                      |
	+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
	|  1 | SIMPLE      | t1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |   100.00 | NULL                                       |
	|  1 | SIMPLE      | t2    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where; Using join buffer (hash join) |
	+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+

PRIMARY

对于包含UNION、UNION ALL或者子查询的大查询来说，它是由几个小查询组成的，其中最左边的那个查询的select_type值就是PRIMARY，比方说：

	EXPLAIN SELECT * FROM t1  UNION SELECT * FROM t2;

	+----+--------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+
	| id | select_type  | table      | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra           |
	+----+--------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+
	|  1 | PRIMARY      | t1         | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |   100.00 | NULL            |
	|  2 | UNION        | t2         | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |   100.00 | NULL            |
	| NULL | UNION RESULT | <union1,2> | NULL       | ALL  | NULL          | NULL | NULL    | NULL | NULL |     NULL | Using temporary |
	+----+--------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+

从结果中可以看到，最左边的小查询SELECT * FROM s1对应的是执行计划中的第一条记录，它的select_type值就是PRIMARY。

UNION

对于包含UNION或者UNION ALL的大查询来说，它是由几个小查询组成的，其中除了最左边的那个小查询以外，其余的小查询select_type的值就是UNION，可以对比上一个例子的效果，这就不多举例子了。
UNION RESULT

MySQL选择使用临时表来完成UNION查询的去重工作，针对该临时表的查询的select_type就是UNION RESULT，例子上边有，就不赘述了。

SUBQUERY

如果包含子查询的查询语句不能够转为对应的semi-join的形式，并且该子查询是不相关子查询，并且查询优化器决定采用将该子查询物化的方案来执行该子查询时，该子查询的第一个SELECT关键字代表的那个查询的select_type就是SUBQUERY，比如下边这个查询：

	EXPLAIN SELECT * FROM s1 AS s1 WHERE s1.key1 IN (SELECT s2.key1 FROM s2 WHERE s2.key1= 'key1') OR s1.key1 = 'key1';

	+----+-------------+-------+------------+------+---------------+----------+---------+-------+-------+----------+-------------+
	| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref   | rows  | filtered | Extra       |
	+----+-------------+-------+------------+------+---------------+----------+---------+-------+-------+----------+-------------+
	|  1 | PRIMARY     | s1    | NULL       | ALL  | idx_key1      | NULL     | NULL    | NULL  | 97124 |   100.00 | Using where |
	|  2 | SUBQUERY    | s2    | NULL       | ref  | idx_key1      | idx_key1 | 303     | const |     1 |   100.00 | Using index |
	+----+-------------+-------+------------+------+---------------+----------+---------+-------+-------+----------+-------------+

可以看到，外层查询的select_type就是PRIMARY，子查询的select_type就是SUBQUERY。需要大家注意的是，由于select_type为SUBQUERY的子查询会被物化，所以只需要执行一遍。注意：如果子查询是进行全表扫描，select_type 就是DEPENDENT SUBQUERY。

DEPENDENT SUBQUERY

如果包含子查询的查询语句不能够转为对应的semi-join的形式，并且该子查询是相关子查询，则该子查询的第一个SELECT关键字代表的那个查询的select_type就是DEPENDENT SUBQUERY，比如下边这个查询：

	EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2 WHERE s1.key2 = s2.key2) OR key3 = 'a';

	+----+--------------------+-------+------------+--------+-------------------+----------+---------+----------------+-------+----------+-------------+
	| id | select_type        | table | partitions | type   | possible_keys     | key      | key_len | ref            | rows  | filtered | Extra       |
	+----+--------------------+-------+------------+--------+-------------------+----------+---------+----------------+-------+----------+-------------+
	|  1 | PRIMARY            | s1    | NULL       | ALL    | idx_key3          | NULL     | NULL    | NULL           | 97124 |   100.00 | Using where |
	|  2 | DEPENDENT SUBQUERY | s2    | NULL       | eq_ref | idx_key2,idx_key1 | idx_key2 | 5       | stuudy.s1.key2 |     1 |    10.00 | Using where |
	+----+--------------------+-------+------------+--------+-------------------+----------+---------+----------------+-------+----------+-------------+

需要大家注意的是，select_type 为 DEPENDENT SUBQUERY 的查询可能会被执行多次。

DEPENDENT UNION

在包含UNION或者UNION ALL的大查询中，如果各个小查询都依赖于外层查询的话，那除了最左边的那个小查询之外，其余的小查询的select_type的值就是DEPENDENT UNION。说的有些绕哈，比方说下边这个查询：

	 EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2 WHERE key1 = 'a' UNION SELECT key1 FROM s1 WHERE key1 = 'b');

	+----+--------------------+------------+------------+------+---------------+----------+---------+-------+-------+----------+--------------------------+
	| id | select_type        | table      | partitions | type | possible_keys | key      | key_len | ref   | rows  | filtered | Extra                    |
	+----+--------------------+------------+------------+------+---------------+----------+---------+-------+-------+----------+--------------------------+
	|  1 | PRIMARY            | s1         | NULL       | ALL  | NULL          | NULL     | NULL    | NULL  | 97124 |   100.00 | Using where              |
	|  2 | DEPENDENT SUBQUERY | s2         | NULL       | ref  | idx_key1      | idx_key1 | 303     | const |     1 |   100.00 | Using where; Using index |
	|  3 | DEPENDENT UNION    | s1         | NULL       | ref  | idx_key1      | idx_key1 | 303     | const |     1 |   100.00 | Using where; Using index |
	| NULL | UNION RESULT       | <union2,3> | NULL       | ALL  | NULL          | NULL     | NULL    | NULL  |  NULL |     NULL | Using temporary          |
	+----+--------------------+------------+------------+------+---------------+----------+---------+-------+-------+----------+--------------------------+

这个查询比较复杂，大查询里包含了一个子查询，子查询里又是由UNION连起来的两个小查询。从执行计划中可以看出来，SELECT key1 FROM s2 WHERE key1 = 'a'这个小查询由于是子查询中第一个查询，所以它的select_type是DEPENDENT SUBQUERY，而SELECT key1 FROM s1 WHERE key1 = 'b'这个查询的select_type就是DEPENDENT UNION。

DERIVED

对于采用物化的方式执行的包含派生表的查询，该派生表对应的子查询的select_type就是DERIVED，比方说下边这个查询：

	EXPLAIN SELECT * FROM (SELECT key1, count(*) as c FROM s1 GROUP BY key1) AS derived_s1 where c > 1;

	+----+-------------+------------+------------+-------+---------------+----------+---------+------+-------+----------+-------------+
	| id | select_type | table      | partitions | type  | possible_keys | key      | key_len | ref  | rows  | filtered | Extra       |
	+----+-------------+------------+------------+-------+---------------+----------+---------+------+-------+----------+-------------+
	|  1 | PRIMARY     | <derived2> | NULL       | ALL   | NULL          | NULL     | NULL    | NULL | 97124 |   100.00 | NULL        |
	|  2 | DERIVED     | s1         | NULL       | index | idx_key1      | idx_key1 | 303     | NULL | 97124 |   100.00 | Using index |
	+----+-------------+------------+------------+-------+---------------+----------+---------+------+-------+----------+-------------+

从执行计划中可以看出，id为2的记录就代表子查询的执行方式，它的select_type是DERIVED，说明该子查询是以物化的方式执行的。id为1的记录代表外层查询，大家注意看它的table列显示的是，表示该查询是针对将派生表物化之后的表进行查询的。

MATERIALIZED

当查询优化器在执行包含子查询的语句时，选择将子查询物化之后与外层查询进行连接查询时，该子查询对应的select_type属性就是MATERIALIZED
UNCACHEABLE SUBQUERY 与 UNCACHEABLE UNION

不常用

partitions

一般情况下我们的查询语句的执行计划的partitions列的值都是NULL。

type

我们前边说过执行计划的一条记录就代表着MySQL对某个表的执行查询时的访问方法，其中的type列就表明了这个访问方法是什么啥，比方说下边这个查询：

EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';

+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key1      | idx_key1 | 303     | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+

可以看到type列的值是ref，表明MySQL即将使用ref访问方法来执行对s1表的查询。但是我们之前只唠叨过对使用InnoDB存储引擎的表进行单表访问的一些访问方法，完整的访问方法如下：system ，const ，eq_ref ，ref ，fulltext ，ref_or_null ，index_merge ，unique_subquery ，index_subquery ，range ，index ，ALL 。

system

当表中只有一条记录并且该表使用的存储引擎的统计数据是精确的，比如MyISAM、Memory，那么对该表的访问方法就是system。比方说我们新建一个MyISAM表，并为其插入一条记录：

	mysql>  CREATE TABLE t(i int) Engine=MyISAM;
	Query OK, 0 rows affected (0.01 sec)

	mysql> INSERT INTO t VALUES(1);
	Query OK, 1 row affected (0.00 sec)

然后我们看一下查询这个表的执行计划：

	EXPLAIN SELECT * FROM t;
	+----+-------------+-------+------------+--------+---------------+------+---------+------+------+----------+-------+
	| id | select_type | table | partitions | type   | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
	+----+-------------+-------+------------+--------+---------------+------+---------+------+------+----------+-------+
	|  1 | SIMPLE      | t     | NULL       | system | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
	+----+-------------+-------+------------+--------+---------------+------+---------+------+------+----------+-------+

可以看到type列的值就是system了。如果把存储引擎改为InnoDB，type就变成 ALL了

	SHOW CREATE TABLE t;
	+-------+--------------------------------------------------------------------------------------------------------------+
	| Table | Create Table                                                                                                 		|
	+-------+--------------------------------------------------------------------------------------------------------------+
	| t     | CREATE TABLE `t` (
	  `i` int DEFAULT NULL
	) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |
	+-------+--------------------------------------------------------------------------------------------------------------+

	EXPLAIN SELECT * FROM t;

	+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
	| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
	+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
	|  1 | SIMPLE      | t     | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
	+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+

const

这个我们前边唠叨过，就是当我们根据主键或者唯一二级索引列与常数进行等值匹配时，对单表的访问方法就是const，比如：

	EXPLAIN SELECT * FROM s1 WHERE id=1;

	+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
	| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
	+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
	|  1 | SIMPLE      | s1    | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
	+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+

eq_ref

在连接查询时，如果被驱动表是通过主键或者唯一二级索引列等值匹配的方式进行访问的（如果该主键或者唯一二级索引是联合索引的话，所有的索引列都必须进行等值比较），则对该被驱动表的访问方法就是eq_ref，比方说：

	EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id=s2.id;

	+----+-------------+-------+------------+--------+---------------+---------+---------+--------------+-------+----------+-------+
	| id | select_type | table | partitions | type   | possible_keys | key     | key_len | ref          | rows  | filtered | Extra |
	+----+-------------+-------+------------+--------+---------------+---------+---------+--------------+-------+----------+-------+
	|  1 | SIMPLE      | s1    | NULL       | ALL    | NULL          | NULL    | NULL    | NULL         | 97124 |   100.00 | NULL  |
	|  1 | SIMPLE      | s2    | NULL       | eq_ref | PRIMARY       | PRIMARY | 4       | stuudy.s1.id |     1 |   100.00 | NULL  |
	+----+-------------+-------+------------+--------+---------------+---------+---------+--------------+-------+----------+-------+

从执行计划的结果中可以看出，MySQL打算将s1作为驱动表，s2作为被驱动表，重点关注s2的访问方法是eq_ref，表明在访问s2表的时候可以通过主键的等值匹配来进行访问。

ref

当通过普通的二级索引列与常量进行等值匹配时来查询某个表，那么对该表的访问方法就可能是ref
fulltext

全文索引

ref_or_null

当对普通二级索引进行等值匹配查询，该索引列的值也可以是NULL值时，那么对该表的访问方法就可能是ref_or_null，比如说：

	EXPLAIN SELECT * FROM s1 WHERE key1='a' OR key1 IS NULL;

	+----+-------------+-------+------------+-------------+---------------+----------+---------+-------+------+----------+-----------------------+
	| id | select_type | table | partitions | type        | possible_keys | key      | key_len | ref   | rows | filtered | Extra                 |
	+----+-------------+-------+------------+-------------+---------------+----------+---------+-------+------+----------+-----------------------+
	|  1 | SIMPLE      | s1    | NULL       | ref_or_null | idx_key1      | idx_key1 | 303     | const |    2 |   100.00 | Using index condition |
	+----+-------------+-------+------------+-------------+---------------+----------+---------+-------+------+----------+-----------------------+

index_merge

一般情况下对于某个表的查询只能使用到一个索引，但我们唠叨单表访问方法时特意强调了在某些场景下可以使用Intersection、Union、Sort-Union这三种索引合并的方式来执行查询，忘掉的回去补一下哈，我们看一下执行计划中是怎么体现MySQL使用索引合并的方式来对某个表执行查询的：

	EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';

	+----+-------------+-------+------------+-------------+-------------------+-------------------+---------+------+------+----------+---------------------------------------------+
	| id | select_type | table | partitions | type        | possible_keys     | key               | key_len | ref  | rows | filtered | Extra                                       |
	+----+-------------+-------+------------+-------------+-------------------+-------------------+---------+------+------+----------+---------------------------------------------+
	|  1 | SIMPLE      | s1    | NULL       | index_merge | idx_key1,idx_key3 | idx_key1,idx_key3 | 303,303 | NULL |    2 |   100.00 | Using union(idx_key1,idx_key3); Using where |
	+----+-------------+-------+------------+-------------+-------------------+-------------------+---------+------+------+----------+---------------------------------------------+

从执行计划的type列的值是index_merge就可以看出，MySQL打算使用索引合并的方式来执行对s1表的查询。

unique_subquery

类似于两表连接中被驱动表的eq_ref访问方法，unique_subquery是针对在一些包含IN子查询的查询语句中，如果查询优化器决定将IN子查询转换为EXISTS子查询，而且子查询可以使用到主键进行等值匹配的话，那么该子查询执行计划的type列的值就是unique_subquery，子查询不用会表，比如下边的这个查询语句：

	EXPLAIN SELECT * FROM s1 WHERE key2 IN (SELECT id FROM s2 where s1.key1 = s2.key1) OR key3 = 'a';

	+----+--------------------+-------+------------+-----------------+------------------+---------+---------+------+-------+----------+-------------+
	| id | select_type        | table | partitions | type            | possible_keys    | key     | key_len | ref  | rows  | filtered | Extra       |
	+----+--------------------+-------+------------+-----------------+------------------+---------+---------+------+-------+----------+-------------+
	|  1 | PRIMARY            | s1    | NULL       | ALL             | idx_key3         | NULL    | NULL    | NULL | 97124 |   100.00 | Using where |
	|  2 | DEPENDENT SUBQUERY | s2    | NULL       | unique_subquery | PRIMARY,idx_key1 | PRIMARY | 4       | func |     1 |    10.00 | Using where |
	+----+--------------------+-------+------------+-----------------+------------------+---------+---------+------+-------+----------+-------------+

可以看到执行计划的第二条记录的type值就是unique_subquery，说明在执行子查询时会使用到id列的索引。

index_subquery

index_subquery与unique_subquery类似，只不过访问子查询中的表时使用的是普通的索引，比如这样：

	EXPLAIN SELECT * FROM s1 WHERE common_field IN (SELECT key3 FROM s2 where s1.key1 = s2.key1) OR key3 = 'a';

	+----+--------------------+-------+------------+----------------+-------------------+----------+---------+------+-------+----------+-------------+
	| id | select_type        | table | partitions | type           | possible_keys     | key      | key_len | ref  | rows  | filtered | Extra       |
	+----+--------------------+-------+------------+----------------+-------------------+----------+---------+------+-------+----------+-------------+
	|  1 | PRIMARY            | s1    | NULL       | ALL            | idx_key3          | NULL     | NULL    | NULL | 97124 |   100.00 | Using where |
	|  2 | DEPENDENT SUBQUERY | s2    | NULL       | index_subquery | idx_key1,idx_key3 | idx_key3 | 303     | func |     1 |    10.00 | Using where |
	+----+--------------------+-------+------------+----------------+-------------------+----------+---------+------+-------+----------+-------------+

range

如果使用索引获取某些范围区间的记录，那么就可能使用到range访问方法，比如下边的这个查询：

	EXPLAIN SELECT * FROM s1 WHERE key1 IN ('a', 'b', 'c');

	+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
	| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
	+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
	|  1 | SIMPLE      | s1    | NULL       | range | idx_key1      | idx_key1 | 303     | NULL |    3 |   100.00 | Using index condition |
	+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+

	或者

	 EXPLAIN SELECT * FROM s1 WHERE key1 > 'a' AND key1 < 'b';

	+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
	| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
	+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
	|  1 | SIMPLE      | s1    | NULL       | range | idx_key1      | idx_key1 | 303     | NULL |    1 |   100.00 | Using index condition |
	+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+

index

当我们可以使用索引覆盖，但需要扫描全部的索引记录时（不需要回表），该表的访问方法就是index，比如这样：

	EXPLAIN SELECT key_part2 FROM s1 WHERE key_part3 = 'a';

	+----+-------------+-------+------------+-------+---------------+--------------+---------+------+-------+----------+--------------------------+
	| id | select_type | table | partitions | type  | possible_keys | key          | key_len | ref  | rows  | filtered | Extra                    |
	+----+-------------+-------+------------+-------+---------------+--------------+---------+------+-------+----------+--------------------------+
	|  1 | SIMPLE      | s1    | NULL       | index | idx_key_part  | idx_key_part | 909     | NULL | 97124 |    10.00 | Using where; Using index |
	+----+-------------+-------+------------+-------+---------------+--------------+---------+------+-------+----------+--------------------------+

上述查询中的搜索列表中只有key_part2一个列，而且搜索条件中也只有key_part3一个列，这两个列又恰好包含在idx_key_part这个索引中，可是搜索条件key_part3不能直接使用该索引进行ref或者range方式的访问，只能扫描整个idx_key_part索引的记录，所以查询计划的type列的值就是index。

ALL

最熟悉的全表扫描

	EXPLAIN SELECT * FROM s1;

	+----+-------------+-------+------------+------+---------------+------+---------+------+-------+----------+-------+
	| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows  | filtered | Extra |
	+----+-------------+-------+------------+------+---------------+------+---------+------+-------+----------+-------+
	|  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 97124 |   100.00 | NULL  |
	+----+-------------+-------+------------+------+---------------+------+---------+------+-------+----------+-------+

一般来说，这些访问方法按照我们介绍它们的顺序性能依次变差。其中除了All这个访问方法外，其余的访问方法都能用到索引，除了index_merge访问方法外，其余的访问方法都最多只能用到一个索引。

possible_keys和key

在EXPLAIN语句输出的执行计划中，possible_keys列表示在某个查询语句中，对某个表执行单表查询时可能用到的索引有哪些，key列表示实际用到的索引有哪些，比方说下边这个查询：

EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key3 = 'a';

+----+-------------+-------+------------+------+-------------------+----------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys     | key      | key_len | ref   | rows | filtered | Extra       |
+----+-------------+-------+------------+------+-------------------+----------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key1,idx_key3 | idx_key3 | 303     | const |    1 |     5.00 | Using where |
+----+-------------+-------+------------+------+-------------------+----------+---------+-------+------+----------+-------------+

上述执行计划的possible_keys列的值是idx_key1,idx_key3，表示该查询可能使用到idx_key1,idx_key3两个索引，然后key列的值是idx_key3，表示经过查询优化器计算使用不同索引的成本后，最后决定使用idx_key3来执行查询比较划算。

不过有一点比较特别，就是在使用index访问方法来查询某个表时，possible_keys列是空的，而key列展示的是实际使用到的索引，比如这样：

EXPLAIN SELECT key_part2 FROM s1 WHERE key_part3 = 'a';

+----+-------------+-------+------------+-------+---------------+--------------+---------+------+-------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key          | key_len | ref  | rows  | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+--------------+---------+------+-------+----------+--------------------------+
|  1 | SIMPLE      | s1    | NULL       | index | idx_key_part  | idx_key_part | 909     | NULL | 97124 |    10.00 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+--------------+---------+------+-------+----------+--------------------------+

另外需要注意的一点是，possible_keys列中的值并不是越多越好，可能使用的索引越多，查询优化器计算查询成本时就得花费更长时间，所以如果可以的话，尽量删除那些用不到的索引。

key_len

key_len列表示当优化器决定使用某个索引执行查询时，该索引记录的最大长度，它是由这三个部分构成的：

对于使用固定长度类型的索引列来说，它实际占用的存储空间的最大长度就是该固定值，对于指定字符集的变长类型的索引列来说，比如某个索引列的类型是VARCHAR(100)，使用的字符集是utf8，那么该列实际占用的最大存储空间就是100 × 3 = 300个字节。使用的是utf8mb4，那么实际占用的最大存储空间就是100 x 4 = 400个字节。
如果该索引列可以存储NULL值，则 key_len 比 不可以存储NULL值 时 多1个字节。
对于变长字段来说，都会有2个字节的空间来存储该变长列的实际长度。

下面这些例子使用的都是utf8mb4编码集：

EXPLAIN SELECT * FROM s2 WHERE id = 5;

+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s2    | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+

由于id列的类型是INT，并且不可以存储NULL值，所以在使用该列的索引时key_len大小就是4。当索引列可以存储NULL值时，比如：

EXPLAIN SELECT * FROM s2 WHERE key2 = 5;

+----+-------------+-------+------------+-------+---------------+----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+----------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s2    | NULL       | const | idx_key2      | idx_key2 | 5       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+----------+---------+-------+------+----------+-------+

可以看到key_len列就变成了5，比使用id列的索引时多了1。

对于可变长度的索引列来说，比如下边这个查询：

EXPLAIN SELECT * FROM s2 WHERE key3 = 'a';

+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s2    | NULL       | ref  | idx_key3      | idx_key3 | 403     | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+

由于key1列的类型是VARCHAR(100)，所以该列实际最多占用的存储空间就是400字节，又因为该列允许存储NULL值，所以key_len需要加1，又因为该列是可变长度列，所以key_len需要加2，所以最后ken_len的值就是403。

前边在说InnoDB行格式的时候提到，存储变长字段的实际长度不是可能占用1个字节或者2个字节么？为什么现在不管三七二十一都用了2个字节？这里需要强调的一点是，执行计划的生成是在MySQL server层中的功能，并不是针对具体某个存储引擎的功能，MySQL的设计者在执行计划中输出key_len列主要是为了让我们区分某个使用联合索引的查询具体用了几个索引列，而不是为了准确的说明针对某个具体存储引擎存储变长字段的实际长度占用的空间到底是占用1个字节还是2个字节。比方说下边这个使用到联合索引idx_key_part的查询：

EXPLAIN SELECT * FROM s2 WHERE key_part1 = 'a';

+----+-------------+-------+------------+------+---------------+--------------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key          | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s2    | NULL       | ref  | idx_key_part  | idx_key_part | 403     | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------+------+----------+-------+

我们可以从执行计划的key_len列中看到值是403，这意味着MySQL在执行上述查询中只能用到idx_key_part索引的一个索引列，而下边这个查询：

EXPLAIN SELECT * FROM s2 WHERE key_part1 = 'a' AND key_part2 = 'b';

+----+-------------+-------+------------+------+---------------+--------------+---------+-------------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key          | key_len | ref         | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------------+------+----------+-------+
|  1 | SIMPLE      | s2    | NULL       | ref  | idx_key_part  | idx_key_part | 806     | const,const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------------+------+----------+-------+

这个查询的执行计划的ken_len列的值是806，说明执行这个查询的时候可以用到联合索引idx_key_part的两个索引列。如果使用到联合索引idx_key_part的三个索引列，则key_len为 1209

ref

当使用索引列等值匹配的条件去执行查询时，也就是在访问方法是const、eq_ref、ref、ref_or_null、unique_subquery、index_subquery其中之一时，ref列展示的就是与索引列作等值匹配的东东是个啥，比如只是一个常数或者是某个列。大家看下边这个查询：

EXPLAIN SELECT * FROM s2 WHERE key2 = 5;

+----+-------------+-------+------------+-------+---------------+----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+----------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s2    | NULL       | const | idx_key2      | idx_key2 | 5       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+----------+---------+-------+------+----------+-------+

可以看到ref列的值是const，表明在使用idx_key1索引执行查询时，与key1列作等值匹配的对象是一个常数，当然有时候更复杂一点：

EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id;

+----+-------------+-------+------------+--------+---------------+---------+---------+--------------+-------+----------+-------+
| id | select_type | table | partitions | type   | possible_keys | key     | key_len | ref          | rows  | filtered | Extra |
+----+-------------+-------+------------+--------+---------------+---------+---------+--------------+-------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ALL    | PRIMARY       | NULL    | NULL    | NULL         | 97124 |   100.00 | NULL  |
|  1 | SIMPLE      | s2    | NULL       | eq_ref | PRIMARY       | PRIMARY | 4       | study.s1.id |     1 |   100.00 | NULL  |
+----+-------------+-------+------------+--------+---------------+---------+---------+--------------+-------+----------+-------+

可以看到对被驱动表s2的访问方法是eq_ref，而对应的ref列的值是xiaohaizi.s1.id，这说明在对被驱动表进行访问时会用到PRIMARY索引，也就是聚簇索引与一个列进行等值匹配的条件，于s2表的id作等值匹配的对象就是study.s1.id列（注意这里把数据库名也写出来了）。

有的时候与索引列进行等值匹配的对象是一个函数，比方说下边这个查询：

EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s2.key1 = UPPER(s1.key1);

+----+-------------+-------+------------+------+---------------+----------+---------+------+-------+----------+-----------------------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref  | rows  | filtered | Extra                 |
+----+-------------+-------+------------+------+---------------+----------+---------+------+-------+----------+-----------------------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL     | NULL    | NULL | 97124 |   100.00 | NULL                  |
|  1 | SIMPLE      | s2    | NULL       | ref  | idx_key1      | idx_key1 | 403     | func |     1 |   100.00 | Using index condition |
+----+-------------+-------+------------+------+---------------+----------+---------+------+-------+----------+-----------------------+

我们看执行计划的第二条记录，可以看到对s2表采用ref访问方法执行查询，然后在查询计划的ref列里输出的是func ，说明与s2表的key1列进行等值匹配的对象是一个函数。

rows

如果查询优化器决定使用全表扫描的方式对某个表执行查询时，执行计划的rows列就代表预计需要扫描的行数，如果使用索引来执行查询时，执行计划的rows列就代表预计扫描的索引记录行数。比如下边这个查询：

EXPLAIN SELECT * FROM s1 WHERE key3 > 'l';

+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | s1    | NULL       | range | idx_key3      | idx_key3 | 403     | NULL | 1000 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+

我们看到执行计划的rows列的值是1000 ，这意味着查询优化器在经过分析使用idx_key1进行查询的成本之后，觉得满足key1 > 'l'这个条件的记录只有1000条。

filtered

之前在分析连接查询的成本时提出过一个condition filtering的概念，就是MySQL在计算驱动表扇出时采用的一个策略：

如果使用的是全表扫描的方式执行的单表查询，那么计算驱动表扇出时需要估计出满足搜索条件的记录到底有多少条。
如果使用的是索引执行的单表扫描，那么计算驱动表扇出的时候需要估计出满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。

比方说下边这个查询：

 EXPLAIN SELECT * FROM s1 WHERE key3 > 'l' AND common_field = 'k';

+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | s1    | NULL       | range | idx_key3      | idx_key3 | 403     | NULL | 1000 |    10.00 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+------------------------------------+

从执行计划的key列中可以看出来，该查询使用idx_key3索引来执行查询，从rows列可以看出满足key1 > 'l'的记录有1000条。执行计划的filtered列就代表查询优化器预测在这1000条记录中，有多少条记录满足其余的搜索条件，也就是common_field = 'k'这个条件的百分比。此处filtered列的值是10.00，说明查询优化器预测在266条记录中有10.00%的记录满足common_field = 'k'这个条件。

对于单表查询来说，这个filtered列的值没什么意义，我们更关注在连接查询中驱动表对应的执行计划记录的filtered值，比方说下边这个查询：

EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key1 WHERE s1.common_field = 'a';
+----+-------------+-------+------------+------+---------------+----------+---------+----------------+-------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref            | rows  | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+----------+---------+----------------+-------+----------+-------------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | idx_key1      | NULL     | NULL    | NULL           | 97124 |    10.00 | Using where |
|  1 | SIMPLE      | s2    | NULL       | ref  | idx_key1      | idx_key1 | 403     | study.s1.key1 |     1 |   100.00 | NULL        |
+----+-------------+-------+------------+------+---------------+----------+---------+----------------+-------+----------+-------------+

从执行计划中可以看出来，查询优化器打算把s1当作驱动表，s2当作被驱动表。我们可以看到驱动表s1表的执行计划的rows列为97124 ， filtered列为10.00，这意味着驱动表s1的扇出值就是97124× 10.00% = 9712.4，这说明还要对被驱动表执行大约9712次查询。

# mysql

MySQL—执行计划

简介