最近刚过完年，产品需求暂时不算多，研发这边的一些优化的需求提上日程，其中很大一部分就是SQL优化，平时业务里面写的那些性能并不高效的SQL也都要回炉重写，但是确实很耗费时间，很多时候又要改动表结构。
首先我们在要执行的语句前面加一个Explain 再执行，就可以看到这条SQL语句的性能了。
id:
就是简单的ID标志而已，如果是一条语句就只有1，如果Explain一条SQL语句里面包含了N个子查询，ID就会到N。
select_type:
搜索的类型
SIMPLE：简单的单条搜索语句
PRIMARY：包含多条子查询SQL中的主查询语句
SUBQUERY / DEPENDENT SUBQUERY：包含在主查询语句中的子查询语句 / 包含在主查询语句中的子查询语句 且子查询依赖于主查询的（严重消耗性能！例如select * from a where id = (select id from b ) ; 这种select_type可以用union 链接查询语句进行优化）
UNION / DEPENDENT UNION：使用union链接查询 / 子查询依赖于外层查询的
DERIVED：子查询的结果被当作临时表使用的，驱动的子查询
table：
涉及到的表名
type：
数据库表引擎在搜索表数据时候的方法类型，要对type进行优化，首要前提就是必须有索引，主要优化点就是看这里。主要级别类型有七种（性能由低至高）：
（1）all : 导致了全表查询，性能最低，没有用到任何索引。
（2）index：查询的数据被索引所覆盖，并且搜索返回匹配的所有行。
（3）range：使用了索引并且指定了搜索索引覆盖的一个范围，也就是查询条件增加了 where 索引列 between （xx , xx）或者in ， 或者 > 号 < 号，等等。
（4）ref：当type为ref的时候，表那个ref字段列才会有值，ref指的是用到了非唯一性索引并且精确返回了几条数据。
（5）eq_red：使用唯一性索引，并且对于每个索引键的查询返回匹配的唯一一行数据（有且仅有一个），主键索引或者唯一性索引都能做到这一点。属于高精确的查找，性能较高。
（6）const：使用到了主键索引并且仅仅能查到并且返回一条符合条件的SQL，除了主键外的索引做不到这个级别。
（7）System：最高级别的SQL，只有一条数据的系统表或者衍生表只有一条数据的
主查询。
Possible Keys :
引擎进行表查询时候可能用到的索引，若为null，则没有使用到索引，可能情况：表没建立索引或者不规范的SQL语句导致索引失效。
Key：
引擎进行表查询时候确切使用到的索引
key_len：
索引中使用的字节数，长度越短越好。
ref:
显示索引的使用情况，在哪一行，哪一张表，甚至哪一个字段都会显示出来。当且仅当查找级别优化type为ref的时候才会有值。
rows:
引擎进行表搜索时候查找了多少行，当然是越少越好。
Extra:
这里是mysql给我们的一些优化分析提示，相当于小case。
（1）using file sort：
使用到了额外排序，性能消耗巨大。
例如：select a from aa order by b .
（2）using temporary：
使用到了临时表，性能消耗巨大。
例如：select a from aa group by b.
（3）using where
需要回表查询，意思是没有使用到索引的列，不能光从索引树上获得，还得老老实实从表里找
例如：
a 是索引列 , b不是
select a , b from c where a =XXX ;
（4）Null：
用到了部分索引，但是也有回表查询
（5）using index condiction:
使用到了索引，但是搜索的数据没完全被索引覆盖
例如：select a,b from c ;
（6）using index:
使用到了索引，并且搜索返回的数据完全被索引覆盖
例如 a, b ,c 都有索引
select a,b,c from XXX where a=’’ and b = ‘’ and c = ‘’ ;