java架构之路（三）Mysql之Explain使用详解

　　上篇博客，我们详细的说明了mysql的索引存储结构，也就是我们的B+tree的变种，是一个带有双向链表的B+tree。那么我今天来详细研究一下，怎么使用索引和怎么查看索引的使用情况。

我们先来简单的建立几张表。

只有ID加了索引，我们先来运行一下explain，看下结果。

其中包含了id，select_type，table，type，possible_keys，key，key_len，ref，rows，Extra这些列 ，我们来逐个看一下这些都有什么用吧。

id：

id列的编号是 select 的序列号，有几个 select 就有几个id，并且id的顺序是按 select 出现的 顺序增长的。 id列越大执行优先级越高，id相同则从上往下执行，id为NULL最后执行。

例如：EXPLAIN SELECT r.id FROM (SELECT id from student) r

从sql语句我们可以看出来，我们有两个select，也就是有两个id，然后呢，我们会优先运行红颜色的select，也就是id为2的，再运行id为1的select。

select_type列：

select_type 表示对应行是简单还是复杂的查询；大致可以分为如下几类：

　　1)simple:简单查询。查询不包含子查询和union

　　2)primary:复杂查询中最外层的 select

　　3)subquery:包含在 select 中的子查询(不在 from 子句中）

　　4)derived:包含在 from 子句中的子查询。MySQL会将结果存放在一个临时表中，也称为 派生表(derived的英文含义)

　　5)union:在 union 中的第二个和随后的 select

table列： 这一列表示 explain 的一行正在访问哪个表。 当 from 子句中有子查询时，table列是 <derivenN> 格式，表示当前查询依赖 id=N 的查 询，于是先执行 id=N 的查询。 当有 union 时，UNION RESULT 的 table 列的值为<union1,2>，1和2表示参与 union 的 select 行id。

type列：

这一列表示关联类型或访问类型，即MySQL决定如何查找表中的行，查找数据行记录的大概 范围。 依次从最优到最差分别为:system > const > eq_ref > ref > range > index > ALL 一般来说，得保证查询达到range级别，最好达到ref

这里简单再次解释一下。

其中system，const都是主优质的。一般来说使用主键索引是const，system一般是不需要再次查表就可以得到的sql。

eq_ref是primary key 或 unique key 索引的所有部分被连接使用 ，最多只会返回一条符合 条件的记录。这可能是在 const 之外最好的联接类型了，简单的 select 查询不会出现这种 type。

ref相比 eq_ref，不使用唯一索引，而是使用普通索引或者唯一性索引的部分前缀，索引要和某个值相比较，可能会找到多个符合条件的行。

range通常是范围查找的使用索引，index:扫描全表索引，这通常比ALL快一些。ALL:即全表扫描，意味着mysql需要从头到尾去查找所需要的行。通常情况下这需要增加索 引来进行优化了。

possible_keys列： 这一列显示查询可能使用哪些索引来查找。 explain 时可能出现 possible_keys 有列，而 key 显示 NULL 的情况，这种情况是因为表中 数据不多，mysql认为索引对此查询帮助不大，选择了全表查询。 如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查 where 子句看是否可 以创造一个适当的索引来提高查询性能，然后用 explain 查看效果。

key列： 这一列显示mysql实际采用哪个索引来优化对该表的访问。 如果没有使用索引，则该列是 NULL。如果想强制mysql使用或忽视possible_keys列中的索 引，在查询中使用 force index、ignore index。

key_len列：

这一列显示了mysql在索引里使用的字节数，通过这个值可以算出具体使用了索引中的哪些列。

计算方式和你的列设置类型有很大关系

char(n):n字节长度

varchar(n):2字节存储字符串长度，如果是utf-8，则长度 3n +2

tinyint:1字节

smallint:2字节

int:4字节

date:3字节

timestamp:4字节

datetime:8字节

索引最大长度是768字节，当字符串过长时，mysql会做一个类似左前缀索引的处理，将前半 部分的字符提取出来做索引。

ref列：

这一列显示了在key列记录的索引中，表查找值所用到的列或常量，常见的有:const

rows列：

这一列是mysql估计要读取并检测的行数，注意这个不是结果集里的行数。只是一个预估值。

Extra列： 这一列展示的是额外信息。

简单说一下大概常见的都有什么

Using index:使用覆盖索引

Using where:使用 where 语句来处理结果，查询的列未被索引覆盖

Using index condition:查询的列不完全被索引覆盖，where条件中是一个前导列的范围;

Using temporary:mysql需要创建一张临时表来处理查询。出现这种情况一般是要进行优化的，首先是想到用索引来优化。

这里还有很多很多，可以自行去官方文档查看。

上述都是一些概念，不建议背诵下来，开始可以查查文档博客，用多了自然也就记住了。

　　下面我来说一下最左前缀原则，我们上一篇博客提了一下最左前缀原则，但是我们并没有详细说明。

　　我来看一下，假设我们现在有一个表student，有id（主键索引），name，age，address，class（联合索引），createtime

联合索引的使用犹如过桥一样，中间有断路则不在继续使用，假设name为桥上跳板A，address为跳板B，class为跳板C。也就是说，我们在使用ABC时，必须优先使用A再使用B最后是C，并且都要合理运用。

例如select * from student where name = "张三" and class="三班"这时我们只使用了name一个索引，其余的都没有使用，我们可以尝试上面explain自己测试一下，算一下ken_len的值。

我们来说几个特殊的情况，select * from student where name = "张三" age>18 and address="北京" and class="三班" ，在这种情况下，后两列其实都没有用到索引，可以自己脑补一下索引的B+tree自己琢磨一下。

留一个思考题，为什么我们在建表的时候需要设置字段不为空。

　　索引优化的路还很长，后面我会详细的说mysql的索引优化处理。

最近搞了一个个人公众号，会每天更新一篇原创博文，java，python，自然语言处理相关的知识有兴趣的小伙伴可以关注一下。