mysql深度剖析二（根据explain拿到执行计划进行优化）

根据explain拿到执行计划进行优化

id

有几个select就有几个id，越大越先执行，相等时从上往下执行

select_type

simple：简单查询。查询不包含子查询和union；
primary：复杂查询中最外层的 select；
subquery：包含在 select 中的子查询（不在 from 子句中）；
derived：包含在 from 子句中的子查询。MySQL会将结果存放在一个临时表中，也称为派生表（derived的英文含义）；
union：在 union 中的第二个和随后的 select；

table列

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

type字段

一共有8种分为4组情况：
system与const：前者是后者的特例，前者有且只有一行数据，后者用到了主键索引查到了唯一 一行数据；
eq_ref与ref：前者使用了主键或唯一索引进行关联查询，最多只会返回一条符合条件的记录，简单查询不会出现这种；后者使用普通索引或者在关联查询中使用了联合索引的最左前缀法则；
range：用索引进行了范围查询
index与all：前者指只需扫描二级索引中所有叶子节点就能拿到所需数据，即全索引扫描，后者指需要扫描聚集索引中所有叶子节点才能拿到所需的完整数据，即全表扫描。一般加了where条件，会从索引根节点按照二分法开始查找。index比all效率更高一点，因为二级索引的叶子节点比聚集索引的叶子节点包含的数据少，磁盘io效率更高。
null：不用访问用户表；

extra字段

该字段下可能存在几十种情况，但大多数情况很难碰到，并且extra的结果不是很准确，仅作为参考，这里只分析常见情况：
using index：使用覆盖索引，可以这么理解：用二级索引树就可以搞定了；
using index condition ：使用了索引下推
using temporary：对于select distinct xxx …的操作，若xxx字段没有用到索引，则会先建一张临时表，然后再去重，所以优化办法是对xxx字段加索引，此时就会变成using index，即一边从左到右扫描二级索引的叶子节点一边去重，避免了建立临时表，提高了效率；
using filesort：使用了外部排序而没利用索引树叶子节点进行排序，这里有个单路排序和双路排序的概念，单路排序指利用二级索引找到全部数据，再进行排序；双路排序指先根据where条件后的几个字段进行排序，再回表查出完整数据。比如order by xxx，当没有给xxx字段加索引时，会走using fileSort，即在内存或者在磁盘排好序（数据量较大时），当给xxx字段加上索引时，会走using index，即利用二级索引的叶子节点本身就具有顺序的特征拿到数据；
单路排序有点类似于索引下推，先过滤到符合要求数据的所有字段，再排序，而双路排序则是先过滤到符合要求的排序字段和可以直接定位到数据行的id，接着排序，排好序后，再根据id回表取回其他字段；
所以单路排序占用内存大，但排好序后，结果就出来了；双路排序占用内存小，但排完序后，还要根据id回表查出所有数据；

using where