Mysql的执行计划算是一个平时接触比较少的部分。惭愧，平时的sql优化都是直接看sql，然后一列一列条件的debug，并没有一个科学的统计方法。抽空看了一些关于执行计划的内容，感觉收获颇丰。

执行计划格式首先我们先简单看一下执行计划是什么东西。关联一下简单的订单和订单商品join得到的结果：ok，执行计划表总共有12列，每一列的含义，我们一一道来。1.id，表示每一个子句的操作顺序，id越大，优先级越高。对于每一个平级查询，id是一致的，表示操作的优先级查询；对于有子查询的sql，可以看到子查询的优先级是比外层查询要高的。也比较符合我们的主观意识，先查子表，才能查主表。但是注意，并不是所有带有子查询语句的sql一定会是子查询，例如如下语句：关于sql优化器的优化规则，我不再多讲解，一是本章的主要内容不是讲这方面的内容，二是我自己领悟的也不够。

2.select_type,查询类型

1）SIMPLE，简单查询，表示不包含子查询或者UNION子句2）PRIMARY，表示查询语句包含子查询或者UNION子句，PRIMARY表示外层的语句3）SUBQUEY，子查询语句4）UNION union 位于union中第二个及其以后的子查询被标记为union5）DERIVED 在from列表中包含的子查询被标记为derived（衍生）6）DEPENDENT UNION UNION中的第二个或后面的SELECT语句，取决于外面的查询7）UNION RESULT UNION的结果6和7我本人并不是十分理解，不再加以展示

3.table,需要查询表，这个有可能是数据库表或临时表

4.partitions,匹配到的分区，出现于分表查询中的情况

5.type,访问类型，这个指标是sql查询优化中很重要的一个指标

常会出现的几个枚举值如下：system：表中只有一行记录，相当于系统表const：通过索引一次命中，匹配一行数据    eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配，常用语主键或唯一索引扫描   ref：非唯一性索引扫描，返回匹配某个单独值的所有行，用于=、<或>操作符带索引的列    range：只检索给定范围的行，使用一个索引来选择行，一般用于between、<、>；    index：只遍历索引树；    all：全表扫描；从上到下的执行效率是依次降低的，前5种情况都是理想的索引的情况。通常优化至少到range级别，最好能优化到ref。列举一些例子：system是const的一个特例，表中只有一行数据时使用我在订单编号上建立了唯一索引，通过下图（呃呃，不知道为啥传不了图片了，直接粘结果吧）可以看出，当主键或者唯一索引位于where条件时，那么执行的类型为const

mysql> explain select * from `order` where title = 'C1086407110000019';+----+-------------+-------+------------+-------+---------------+--------+---------+-------+------+----------+-------+| id | select_type | table | partitions | type  | possible_keys | key    | key_len | ref   | rows | filtered | Extra |+----+-------------+-------+------------+-------+---------------+--------+---------+-------+------+----------+-------+|  1 | SIMPLE      | order | NULL       | const | 订单          | 订单   | 1023    | const |    1 |   100.00 | NULL  |+----+-------------+-------+------------+-------+---------------+--------+---------+-------+------+----------+-------+1 row in set, 1 warning (0.00 sec)mysql> explain select * from `order` where id = 1;+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+|  1 | SIMPLE      | order | NULL       | const | PRIMARY       | PRIMARY | 8       | const |    1 |   100.00 | NULL  |+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+1 row in set, 1 warning (0.00 sec)

而eq_ref的区别为，eq_ref使用在关联查询上，如下：

mysql> explain select * from `order` left join order_item on `order`.id = order_item.order_id where `order`.id = 1;+----+-------------+------------+------------+-------+---------------+-----------+---------+-------+------+----------+-------+| id | select_type | table      | partitions | type  | possible_keys | key       | key_len | ref   | rows | filtered | Extra |+----+-------------+------------+------------+-------+---------------+-----------+---------+-------+------+----------+-------+|  1 | SIMPLE      | order      | NULL       | const | PRIMARY       | PRIMARY   | 8       | const |    1 |   100.00 | NULL  ||  1 | SIMPLE      | order_item | NULL       | ref   | 订单号        | 订单号    | 8       | const |    2 |   100.00 | NULL  |+----+-------------+------------+------------+-------+---------------+-----------+---------+-------+------+----------+-------+2 rows in set, 1 warning (0.00 sec)

对于非唯一性索引，比如我们的订单中的用户id，当我们查询时，有可能会使用ref或者range结果如下：

mysql> explain select * from `order` where customer_id = 55029;+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+| id | select_type | table | partitions | type | possible_keys | key         | key_len | ref   | rows | filtered | Extra |+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+|  1 | SIMPLE      | order | NULL       | ref  | customer_id   | customer_id | 8       | const |   10 |   100.00 | NULL  |+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+1 row in set, 1 warning (0.00 sec)mysql> explain select * from `order` where customer_id > 55029 and customer_id < 55129;+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+| id | select_type | table | partitions | type  | possible_keys | key         | key_len | ref  | rows | filtered | Extra                 |+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+|  1 | SIMPLE      | order | NULL       | range | customer_id   | customer_id | 8       | NULL |    1 |   100.00 | Using index condition |+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+1 row in set, 1 warning (0.00 sec)

当然如果没有索引的字段，那么执行方式只能是ALL了。

但是值得注意的是，并不是有了索引就一定不会走索引的。如果字段的差异性太小，例如性别字段，即使建了索引，那么也不会走索引的。这里我举一个例子，我拿来做测试的所有订单表中只有一个卖家，这个字段上是有索引的，但是我们来查询一下：

mysql> explain select * from `order` where seller_id = 19;+----+-------------+-------+------------+------+------------------+------+---------+------+------+----------+-------------+| id | select_type | table | partitions | type | possible_keys    | key  | key_len | ref  | rows | filtered | Extra       |+----+-------------+-------+------------+------+------------------+------+---------+------+------+----------+-------------+|  1 | SIMPLE      | order | NULL       | ALL  | 商家,seller_id   | NULL | NULL    | NULL | 2197 |   100.00 | Using where |+----+-------------+-------+------------+------+------------------+------+---------+------+------+----------+-------------+1 row in set, 1 warning (0.00 sec)

发现实际上innodb并没有选择走索引，因为在这种情况下，走索引比不走索引的开销还要大。关于开销，Innodb是基于CBO进行判断的（更古老的判断方式是RBO，这些内容具体已经记得不是很清楚了，想要了解的需要再查找一些相关资料）。

上述几个值并不是全部的枚举值，例如还有fulltext、 index_merge、 unique_subquery等等，不过出现的频次没有什么上述的几个枚举值高而已。

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL