mysql优化之优化神奇explain属性（mysql本身的执行操作过程）

explain模拟优化器，我可以通过explain来查看mysql是如何处理sql语句，分析查询语句或者表结构的性能瓶颈。 

 语法：explain + sql语句

 比如：

explain select * from tb_order 

执行结果：

 执行结果中：id 、select_type等等。

下面我们来解释一下执行结果每个属性

1.id

• id 执行顺序 ：id分为相同  不同，相同/不同  3种情况， id遵循：在相同的情况下自上而下执行，如果存在不同的情况，id值越大，越先执行 ，那么第三种情况（相同/不同）的就自然而解了。

2.select_type 

它的值包括：SIMPLE,PRIMARY,SUBQUERY,DERIVER(衍生)，UNION,UNION RESULT

1. SIMPLE ：简单的查询，不包括子查询或者UNION
2. PRIMARY ：查询中若包括任何复杂的字部分，最外层被标记为PRIMARY
3. SUBQUERY：在select或者where列表包含子查询
4. DERIVER：在from列表中包含子查询标记为DERIVER  mysql会递归执行这些子查询，把结果放在临时表中
5. UNION：若第二个select出现UNION后面的话  会被标记为UNION，如果说在UNION包含在from子句的子查询中，外层select被标记为DERIVER
6. UNION RESULT：从UNION表中获取合并结果（select）

3.table  ：所在的数据表

4.type（访问的类型:以下 从最好到最差的排序，至少要达到RANG或者REF级别）

SYSTEM > CONST > EQ_REF > REF > RANG > INDEX > ALL

1. SYSTEM：表只要一条数据（等于系统表），这是const类型的特例，平时不会出现。
2. CONST：表示通过索引一次就找到了 ，const用于primary key 或者unique索引。因为只匹配一行数据，所以很快。
3. EQ_REF：唯一索引扫描，对于每个索引建，表中只有一条数据与之匹配。常见与主键或者唯一索引扫描
4. REF ：非唯一性索引扫描，返回所有匹配的所有行
5. RANG ：给定范围，利用索引查找 比如：between and等
6. INDEX ：不利用全表扫描 比all好一点
7. ALL：全表扫描，最垃圾的，开发过程（百万数据量）中必要消除all级别的 

 5.possible_keys（可能用到的索引）

 6. key(实际用到的索引，如果为null的  则没有用到索引   这也是mysql优化的标准之一)

 7. key_len(索引键的长度：使用的字节数，在使用索引的个数相同的情况下，key的长度越短，效率越高)

 8. ref（mysql执行操作的时候 到底引用了哪些索引）

 9.rows：多少条数据需要被优化器查询

 10.Extra : 在其他属性中不方便展示 并且十分重要的东西

1. using fileSort （内部文件排序，也就是说，排序的条件没有用到） 这种情况会糟糕，开发过程中遇到  一定要消除（出现问题的概率为九死一生）。
2. using temporary  ：新建内部临时表 ，完成查询操作之后   再把临时表删除（这样很伤数据库性能，出现问题的概率为十死，必死，必须要消除）
3. using index：执行操作的时候  内部使用了索引  使用了覆盖索引（也就是说你的索引顺序和个数  与内部使用一致）。
4. using where：使用where查询
5. using join buffer ：使用了链接缓存
6. impossible where ：不可能使用where

总结

在做优化的时候  explain 的id ，type， key，rows，Extra 使我们做优化的标准  关注点