Mysql-使用Explain分析你的SQL

引

使用Explain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的，分析你的查询语句或表结构的性能瓶颈

这也是我们调优工作中重要的一环

用法：Explain + SQL语句

通过查看以上字段的信息，可以分析我们的Mysql，接下来逐一讲解每一个字段

演示数据SQL

四张表，每张表两个字段id与content

CREATE TABLE t1(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id)); 
CREATE TABLE t2(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
CREATE TABLE t3(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
CREATE TABLE t4(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id)); 
INSERT INTO t1(content) VALUES(CONCAT('t1_',FLOOR(1+RAND()*1000))); 
INSERT INTO t2(content) VALUES(CONCAT('t2_',FLOOR(1+RAND()*1000)));
INSERT INTO t3(content) VALUES(CONCAT('t3_',FLOOR(1+RAND()*1000)));
INSERT INTO t4(content) VALUES(CONCAT('t4_',FLOOR(1+RAND()*1000)));

文章目录

Mysql-使用Explain分析你的SQL

引
id
SELECT TYPE
Table
Type索引分析
Possible_keys
Key
Key_len
Ref
rows
Extra

id

这是第一个字段，代表select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序

EXPLAIN SELECT * FROM t1,t2,t3 WHERE t1.id = t2.id AND t2.id = t3.id

这张图可以表示查询中操作表（t1-t2-t3）的顺序

在id相同的情况下，执行顺序由上至下

也就是说，先查t1，再查t2，最后查t3

再看下面这条，这是一条嵌套子查询

EXPLAIN SELECT t1.id from t1 WHERE t1.id IN
(SELECT t2.id FROM t2 WHERE t2.id IN
(SELECT t3.id FROM t3 WHERE t3.content='')
);

嵌套子查询下，各表的id可以看出，是不同的，这种情况下

id 值越大优先级越高，越先被执行

也就是说，先查t3，再查t2，最后查t1

小结：id 号每个号码，表示一趟独立的查询。一个 sql 的查询趟数越少越好

SELECT TYPE

代表查询的类型，主要是用于区别普通查询、联合查询、子查询等的复杂查询，看上图，就出现了简单查询（Simple）与依赖子查询（DEPEDENT SUBQUERY ）与主查询（Primary）

以下列出Mysql的所有查询类型，您大概看一遍就得了

SIMPLE

简单的 select 查询,查询中不包含子查询或者 UNION

PRIMARY

查询中若包含任何复杂的子部分，最外层查询则被标记为 Primary

如

EXPLAIN SELECT * FROM (SELECT t1.content FROM t1) a  ;

DERIVED

在 FROM 列表中包含的子查询被标记为 DERIVED(衍生) ，MySQL 会递归执行这些子查询, 把结果放在临时表里，如上图

SUBQUERY

在SELECT或WHERE列表中包含了子查询

如

EXPLAIN SELECT t2.id FROM t2 WHERE t2.id = (SELECT t3.id FROM t3 WHERE t3.id =2 ) ;

DEPEDENT SUBQUERY

在SELECT或WHERE列表中包含了子查询,子查询基于外层

如

EXPLAIN SELECT t2.id FROM t2 WHERE t2.id IN (SELECT t3.id FROM t3 WHERE t3.content ='PfkHfe' ) ;

UNCACHEABLE SUBQUERY

无法使用缓存的子查询

UNION

若第二个SELECT出现在UNION之后，则被标记为UNION；若UNION包含在FROM子句的子查询中,外层SELECT将被标记为：DERIVED

如

EXPLAIN 
SELECT t2.id ,t2.content FROM t2 
UNION ALL
SELECT t3.id ,t3.content FROM t3 ;

UNION RESULT

从UNION表获取结果的SELECT

如上图

Table

顾名思义，无需多说

Type索引分析

type 是查询的访问类型,是较为重要的一个指标，结果值从最好到最坏依次是：

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

类型越靠前代表性能越高，速度越快

一般来说，得保证查询至少达到 range 级别，最好能达到 ref

下面我们来逐一分析

System

表只有一行记录（等于系统表），这是 const 类型的特列，平时不会出现，这个也可以忽略不计
Const

表示通过索引一次就找到了,const 用于比较 primary key 或者 unique 索引，因为只匹配一行数据，所以很快

如：将主键置于 where 列表中，MySQL 就能将该查询转换为一个常量
```
EXPLAIN
SELECT * FROM (SELECT * FROM t1 WHERE t1.id=1) s ; 
```
eq_ref

唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描<
```
EXPLAIN 
SELECT * FROM t1 ,t2 WHERE t1.id = t2.id ; 
```
ref

非唯一性索引扫描，返回匹配某个单独值的所有行.本质上也是一种索引访问，它返回所有匹配某个单独值的行，

然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体
- 没用索引前：
```
EXPLAIN 
SELECT * FROM t1 ,t2 WHERE t1.content = t2.content ; 
```
  可见，没建立索引的时候，t1，t2表的type都来到了ALL级别，即全表扫描
- 使用索引：
```
create index idx_ctnt on t2(content) ; 
EXPLAIN 
SELECT * FROM t1 ,t2 WHERE t1.content = t2.content ; 
```
  针对t2表的content字段建立索引
  
  t2表的type来到ref类型
Range

只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引一般就是在你的 where 语句中出现了 between、<、>、in 等的查询，这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束语于一点，不用扫描全部索引

很简单，就不列例子了
Index

出现index是sql使用了索引但是没有通过索引进行过滤

一般是使用了覆盖索引或者是利用索引进行了排序分组

关于覆盖索引，我后面会说到，这个也比较简单，不给出例子，说白一点，就是你建了索引但是没用到，用到了主键索引
ALL

Full Table Scan，将遍历全表以找到匹配的行

介于之间的，还有

index_merge

在查询过程中需要多个索引组合使用，通常出现在有 or 的关键字的 sql 中
ref_or_null

对于某个字段既需要关联条件，也需要 null 值的情况下，查询优化器会选择用 ref_or_null 连接查询
```
EXPLAIN 
SELECT * FROM t2 WHERE t2.content is NULL OR t2.content='abc' ; 
```

index_subquery

利用索引来关联子查询，不再全表扫描

CREATE INDEX idx_ctnt ON t3(content) ; 
EXPLAIN 
SELECT * FROM t2 WHERE t2.content IN
(SELECT t3.content FROM t3);

好了，可能出现的性能参数都介绍完了，现在各位看Type就可以知道自己的SQL语句使用索引的情况了，合理使用索引，能够大幅提高你的SQL性能哦

Possible_keys

显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用

Key

实际使用的索引。如果为NULL，则没有使用索引

Key_len

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。 key_len 字段能够帮你检查是否充分的

利用上了索引。ken_len 越长，说明索引使用的越充分

Ref

显示索引哪一列被使用，哪些列或常量被用于查找索引列上的值

rows

rows 列显示 MySQL 认为它执行查询时必须检查的行数，越少越好！

Extra

其他额外信息，这块地方可得好好说说，因为它也很重要

出现Using filesort

说明 mysql 会shou对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL 中无法利用索引完成的排序操作称为“文件排序”

可见，Mysql无法使用主键索引进行排序，而要对ename列进行排序

优化策略：对ename列建立索引
出现Using temporary

使了用临时表保存中间结果，MySQL 在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group

表中同时对ename进行了分组
- 优化策略：同上
Using index

代表相应的 select 操作中使用了覆盖索引(Covering Index)，避免访问了表的数据行，效率不错！
如果同时出现 using where，表明索引被用来执行索引键值的查找;如果没有同时出现 using where，表明索引只是用来读取数据而非利用索引执行查找
Using Index_condition
使用了索引下推
将存储引擎的数据取出，在Server层处理而非在存储引擎中处理，
索引下推是由优化器自动处理的
Using where

表明使用了where过滤
出现Using join buffer

使用了连接缓存
impossible where

where 子句的值总是 false，不能用来获取任何元组