EXPLAIN 或 DESCRIBE语句的语法形式如下:
- EXPLAIN SELECT select_options
- # 或者 两个是一样的
- DESCRIBE SELECT select_options
EXPLAIN
语句输出的各个列的作用如下列名 | 描述 |
---|---|
id | 在一个大的查询语句中每个SELECT关键字都对应一个 唯一的id |
select_type | SELECT关键字对应的那个查询的类型 |
table | 表名 |
partitions | 匹配的分区信息 |
type | 针对单表的访问方法(重要) |
possible_keys | 可能用到的索引 |
key | 实际上使用的索引 |
key_len | 实际使用到的索引长度 |
ref | 当使用索引列等值查询时,与索引列进行等值匹配的对象信息 |
rows | 预估的需要读取的记录条数 |
filtered | 某个表经过搜索条件过滤后剩余记录条数的百分比 |
Extra | 一些额外的信息 |
表名
不论我们的查询语句有多复杂,里边儿 包含了多少个表
,到最后也是需要对每个表进行 单表访问
的,所 以MySQL规定EXPLAIN语句输出的每条记录都对应着某个单表的访问方法,该条记录的table列代表着该 表的表名(有时不是真实的表名字,可能是简称)
- #1. table:表名
- #查询的每一行记录都对应着一个单表
- explain select count(*) from s1;
- #s1:驱动表 s2:被驱动表
- EXPLAIN SELECT * FROM s1 INNER JOIN s2;
- # 驱动表和被驱动表是 优化器决定的,他认为哪个比较好久用哪个
用到多少个表,就会有多少条记录
正常来说一个select 一个id ,也有例外的可能,查询优化器做了优化
EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';
EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a';
查询优化器优化
- ######查询优化器可能对涉及子查询的查询语句进行重写,转变为多表查询的操作########
- EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field = 'a');
运行结果: id 只有一个,原因是查询优化器做了优化
Union去重
原本想的1个select 一个 id , 预计两个。
- #Union去重
- # union 去重,union all 不去重
- EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;
# union all 不去重 所以不需要放在临时表里面 mysql> EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2;
小结:
一条大的查询语句里边可以包含若干个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) |