如何对SQL进行优化查询之使用explain关键字进行分析？

（一）通过关键字explain的分析我们可以得出什么结果？

在这里插入图片描述
（1）id： 可以用来看出来先执行的顺序，也就是当id值越大，就越先被MySQL执行，如果id相同的话可以认为是同一组，按照从上到下顺序执行

（2）.select_type： 能够看出来你的查询类型，是简单查询、子查询、主键查询等等。所以他可能会出现六种情况

SIMPLE：这个就表示当前就是简单查询
PRIMARY：这个表示当前执行的是主键查询
SUBQUERY：这个表示当前在select或者where列表中包含了子查询
DERIVED：在from列表中包含的查询被标记为DERIVED（衍生），而且MySQL会递归执行这些子查询，把结果放到临时表中
UNION：若在第二个SELECT出现UNION之后，就被标记为 UNION；若UNION包含在FROM子句的子查询中，外层的select将会被标记为DERIVED
UNION RESULT：从 UNOIN表获取结果的result

（3） table： 就是该行所引用的表名

（4）type： 显示了查询使用到了那种类型，从最优的查询到最差的排序为：system>const>eq_ref> range> index > ALL(全表扫描)

system：表只有一行记录（相当于系统表），这是const类型的特例
const：表示通过索引一次就找到了，const主要用于primary key 或者unique索引，因为只匹配一行数据，比如将主键置于where列表中，MySQL就能将该查询转换为一个常量。
eq_ref：唯一性扫描索引，对于每个索引键，表中只有一条记录与之对应
ref：这个表示非唯一行索引扫描，返回的是匹配某个字段的所有行，本质上也是一中索引访问，但是它会找到符合条件的所有行记录
range：只检索给定范围的行，使用一个索引来选择行，key列显示了使用到了那个索引，一般是在where语句中使用到了between、>、<和in条件查询等。这种范围扫描索引比全表扫描要好，因为他只需要开始于索引的某一点，结束的另一点，不需要进行全表扫描了
index：虽然index 和 all 都是进行全表扫描的，但是index是通过索引查询的数据，而 all 是直接从硬盘中进行全表扫描的
all：这个就是通过从磁盘上进行全表扫描的

（5）possible_key: MySQL可能会用到那些索引在该表中找到行级记录

（6）key： 显示MySQL最终实际决定使用的键(索引)。如果没有选择索引,键是NULL

（7）key_len： 显示MySQL决定使用的键长度。如果键是NULL,则长度为NULL。

（8）ref： 显示索引的哪一列被使用了，如果可能的话，是一个常数，哪些列或者常量被用于查找索引列上的值

（9）rows： 显示MySQL认为它执行查询时必须检查的行数。多行之间的数据相乘可以估算要处理的行数。

（10）filtered： 显示了通过条件过滤出的行数的百分比估计值。

（11）Extra： 就是除了以上MySQL要展示的重要的信息之外的一个附加信息

Using filesort ：（也就是无法利用索引完成的排序操作）这个表示在使用索引查询数据的时候，MySQL使用的并不是你自己定义好的索引，而是自己又创建一个外部索引来进行查询的（MySQL需要额外的一次传递，为了找出如何安排顺序检索行，一般出现这个说明查询性能大大已经大大降低了）
Using temporary： 这个表示为了解决查询,MySQL需要创建一个临时表来容纳结果，而且中间过程需要先吧数据拷贝到临时表中，然后在删除临时表（这个已经严重到不能忍了，迫在眉睫需要优化）
Using index： 这个就比较美了，如果出现这个说明你建立的索引都全部被用到了，也就是索引覆盖，可以说效率是非常的高了
Not exists： MySQL能够对查询进行LEFT JOIN优化,发现1个匹配LEFT JOIN标准的行后,不再为前面的的行组合在该表内检查更多的行