MySQL 5.7 查看理解SQL执行计划

可以使用EXPLAIN语句查看SQL的执行计划，执行计划的信息来自于优化器。

在MySQL 5.7，可以查看SELECT, DELETE, INSERT, REPLACE, 和 UPDATE语句的执行计划。

在MySQL 5.7.3，EXPLAIN EXTENDED可以获取更详细的执行计划信息，EXPLAIN PARTITIONS在获取有分区表的执行计划时很有用。

FORMAT选项可以用来选择输出的格式。TRADITIONAL代表以表格形式输出，它是默认的输出格式。JSON格式代表以JSON格式输出，输出结果中包含扩展的执行计划信息和分区表信息。

如果索引没有正常使用，可以通过运行ANALYZE TABLE命令来更新表的统计信息，例如键值的cardinality，这会影响到优化器的选择。

mysql> explain select * from emp e where e.deptno not in (select deptno from dept d);
+----+--------------------+-------+-----------------+---------------+---------+---------+------+------+-------------------------------------------------+
| id | select_type        | table | type            | possible_keys | key     | key_len | ref  | rows | Extra                                           |
+----+--------------------+-------+-----------------+---------------+---------+---------+------+------+-------------------------------------------------+
|  1 | PRIMARY            | e     | ALL             | NULL          | NULL    | NULL    | NULL |   14 | Using where                                     |
|  2 | DEPENDENT SUBQUERY | d     | unique_subquery | PRIMARY       | PRIMARY | 4       | func |    1 | Using index; Using where; Full scan on NULL key |
+----+--------------------+-------+-----------------+---------------+---------+---------+------+------+-------------------------------------------------+
2 rows in set (0.00 sec)

输出字段说明：

id     查询的执行顺序号
select_type     查询类型，包括：

SIMPLE     简单查询（不使用UNION或子查询）
PRIMARY     最外层的SELECT语句
UNION     在UNION结构中的第二个及以上的SELECT语句
DEPENDENT UNION      在UNION结构中的第二个及以上的SELECT语句，依赖外层查询
UNION RESULT     UNION的结果
SUBQUERY     子查询中的第一个SELECT语句
DEPENDENT SUBQUERY     子查询中的第一个SELECT语句，依赖于外层查询
DERIVED      子查询中FROM后面的语句
MATERIALIZED     物化视图子查询
UNCACHEABLE SUBQUERY     查询结果没有被缓存且需要重新外层查询计算每行数据的子查询
UNCACHEABLE UNION UNION    结构中第二个及之后的SELECT语句且没有生成查询缓存

table     表名
type     表连接的类型，包括：

system     表中只有一行数据，这是cost连接类型的一种特殊情况
const     表中只有一行匹配记录，且在查询中被最先读取
eq_ref     和之前的表作nested loop连接时，每次两个表中连接字段相比，都有一行匹配的记录。当索引中的所有部分被用于连接且索引是主键索引或UNIQUE非空索引时，会使用这种类型。
ref     每次和之前的表做连接时，读取所有符合条件的索引值。如果连接使用索引的最左边前缀字段，或者索引不是主键或UNIQUE索引，会用到这种连接方式，也就是说如果连接不能基于每个符合连接条件的索引值选择出单独的一行，则会使用这种连接方式。
fulltext     使用FULLTEXT索引来建立连接
ref_or_null     连接类型类似ref，除此之外，MySQL会额外扫描出包含NULL值的行。这种连接方式通常用于有子查询的情形下。
index_merge     使用索引合并的连接方式。在这种情况下，key字段会包含使用的索引，key_len包含使用索引的最长索引部分。
unique_subquery      这种连接方式在某种情况下会代替eq_ref，如value IN (SELECT primary_key FROM single_table WHERE some_expr)，这种方式使用索引查询功能代替子查询，以获得更好的执行效率。
index_subquery      这种连接方式类似unique_subquery。它会代替IN子查询，但是它适用于非unique索引的子查询，如value IN (SELECT key_column FROM single_table WHERE some_expr)
range     使用索引扫描出指定范围的行。key字段指示使用的索引。key_len指示索引的最大长度。ref字段会显示NULL
index     这种索引连接类型和ALL相同，除了索引树被扫描到。这会出现在两种情况下：一、如果该索引是一个覆盖索引查询,且只扫描出索引树。在这种情况下，Extra字段会显示Using index。二、通过索引顺序来执行全表扫描。
ALL     和之前表做连接时，每次两表关联时都做全表扫描。

possible_keys     可供选择的索引
key     实际选择的索引
key_len      选择的索引长度
ref     显示和索引相比较的字段或常量，如果这个字段的值是func，这个值会用在函数的结果中。
rows     估计的表的行数
Extra     额外信息

mysql> explain select * from buy_log where userid=2;
+----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+
| id | select_type | table   | type | possible_keys   | key    | key_len | ref   | rows | Extra |
+----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+
|  1 | SIMPLE      | buy_log | ref  | userid,userid_2 | userid | 4       | const |    1 | NULL  |
+----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+
1 row in set (0.00 sec)

(04:14:50) [dmcdbMTNNG]> explain select count(*) from ADDSubscribers where timestamp between 1483351200 and 1483354800;
+----+-------------+----------------+-------+---------------+-----------+---------+------+---------+-----------------------------------+
| id | select_type | table          | type  | possible_keys | key       | key_len | ref  | rows    | Extra                             |
+----+-------------+----------------+-------+---------------+-----------+---------+------+---------+-----------------------------------+
|  1 | SIMPLE      | ADDSubscribers | range | Timestamp     | Timestamp | 8       | NULL | 3515427 | Using where with pushed condition |
+----+-------------+----------------+-------+---------------+-----------+---------+------+---------+-----------------------------------+
1 row in set (0.00 sec)

这个信息只适用于NDB表。MySQL Cluster使用这个条件来提高效率。

Using where with pushed condition (JSON property: message)
This item applies to NDB tables only. It means that MySQL Cluster is using the Condition Pushdown
optimization to improve the efficiency of a direct comparison between a nonindexed column and a
constant. In such cases, the condition is “pushed down” to the cluster's data nodes and is evaluated on
all data nodes simultaneously. This eliminates the need to send nonmatching rows over the network, and
can speed up such queries by a factor of 5 to 10 times over cases where Condition Pushdown could be
but is not used. For more information, see Section 9.2.1.5, “Engine Condition Pushdown Optimization”.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26506993/viewspace-2112440/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26506993/viewspace-2112440/