共计 2330 个字符，预计需要花费 6 分钟才能阅读完成。
前言：这篇文章次要讲 explain 如何应用，还有 explain 各种参数概念，之后会讲优化
一、Explain 用法
模仿 Mysql 优化器是如何执行 SQL 查问语句的，从而晓得 Mysql 是如何解决你的 SQL 语句的。剖析你的查问语句或是表构造的性能瓶颈。
语法：Explain + SQL 语句;
如：Explain select * from user; 会生成如下 SQL 剖析后果，上面具体对每个字段进行详解
二、id
是一组数字，代表多个表之间的查问程序，或者蕴含子句查问语句中的程序，id 总共分为三种状况，顺次详解
- id 雷同，执行程序由上至下
- id 不同，如果是子查问，id 号会递增，id 值越大优先级越高，越先被执行
- id 雷同和不同的状况同时存在
三、select_type
select_type 蕴含以下几种值
- simple
- primary
- subquery
- derived
- union
- union result
simple
简略的 select 查问，查问中不蕴含子查问或者 union 查问
primary
如果 SQL 语句中蕴含任何子查问，那么子查问的最外层会被标记为 primary
subquery
在 select 或者 where 里蕴含了子查问，那么子查问就会被标记为 subQquery，同三. 二同时呈现
derived
在 from 中蕴含的子查问，会被标记为衍生查问，会把查问后果放到一个长期表中
union / union result
如果有两个 select 查问语句，他们之间用 union 连起来查问，那么第二个 select 会被标记为 union，union 的后果被标记为 union result。它的 id 是为 null 的
四、table
示意这一行的数据是哪张表的数据
五、type
type 是代表 MySQL 应用了哪种索引类型，不同的索引类型的查问效率也是不一样的，type 大抵有以下品种
- system
- const
- eq_ref
- ref
- range
- index
- all
system
表中只有一行记录，system 是 const 的特例，简直不会呈现这种状况，能够忽略不计
const
将主键索引或者惟一索引放到 where 条件中查问，MySQL 能够将查问条件转变成一个常量，只匹配一行数据，索引一次就找到数据了
eq_ref
在多表查问中，如 T1 和 T2，T1 中的一行记录，在 T2 中也只能找到惟一的一行，说白了就是 T1 和 T2 关联查问的条件都是主键索引或者惟一索引，这样能力保障 T1 每一行记录只对应 T2 的一行记录
举个不太失当的例子，EXPLAIN SELECT * from t1 , t2 where t1.id = t2.id
ref
不是主键索引，也不是惟一索引，就是一般的索引，可能会返回多个符合条件的行。
range
体现在对某个索引进行区间范畴检索，个别呈现在 where 条件中的 between、and、<、>、in 等范畴查找中。
index
将所有的索引树都遍历一遍，查找到符合条件的行。索引文件比数据文件还是要小很多，所以比不必索引全表扫描还是要快很多。
all
没用到索引，单纯的将表数据全副都遍历一遍，查找到符合条件的数据
六、possible_keys
此次查问中波及字段上若存在索引，则会被列出来，示意可能会用到的索引，但并不是实际上肯定会用到的索引
七、key
此次查问中实际上用到的索引
八、key_len
示意索引中应用的字节数，通过该属性能够晓得在查问中应用的索引长度，留神：这个长度是最大可能长度，并非理论应用长度，在不损失精确性的状况下，长度越短查问效率越高
九、ref
显示关联的字段。如果应用常数等值查问，则显示 const，如果是连贯查问，则会显示关联的字段。
- tb_emp 表为非唯一性索引扫描，理论应用的索引列为 idx_name，因为 tb_emp.name=’rose’ 为一个常量，所以 ref=const。
- tb_dept 为惟一索引扫描，从 sql 语句能够看出，理论应用了 PRIMARY 主键索引，ref=db01.tb_emp.deptid 示意关联了 db01 数据库中 tb_emp 表的 deptid 字段。
十、rows
依据表信息统计以及索引的应用状况，大抵估算说要找到所需记录须要读取的行数，rows 越小越好
十一、extra
不适宜在其余列显示进去，但在优化时非常重要的信息
using fileSort（重点优化）
俗称 ” 文件排序 ”，在数据量大的时候简直是“死里逃生”，在 order by 或者在 group by 排序的过程中，order by 的字段不是索引字段，或者 select 查问字段存在不是索引字段，或者 select 查问字段都是索引字段，然而 order by 字段和 select 索引字段的程序不统一，都会导致 fileSort
using temporary（重点优化）
应用了长期表保留两头后果，常见于 order by 和 group by 中。
USING index（重点）
示意相应的 select 操作中应用了笼罩索引（Coveing Index）, 防止拜访了表的数据行，效率不错！如果同时呈现 using where，表明索引被用来执行索引键值的查找；如果没有同时呈现 using where，外表索引用来读取数据而非执行查找动作。
Using wher
表明应用了 where 过滤
using join buffer
应用了连贯缓存
impossible where
where 子句的值总是 false，不能用来获取任何元组
select tables optimized away
在没有 GROUPBY 子句的状况下，基于索引优化 MIN/MAX 操作或者 对于 MyISAM 存储引擎优化 COUNT(*) 操作，不用等到执行阶段再进行计算，查问执行打算生成的阶段即实现优化。
distinct
优化 distinct，在找到第一匹配的元组后即进行找同样值的工作
