MySQL 性能分析--Explain关键字

Explain怎么玩：

explain + SQL语句

explain执行计划各个字段的含义：

1.★id：

id数字大的优先级最高
此字段代表的是 表的加载顺序，小表驱动大表

2.select_type:

查询的类型，主要是用于区别
普通查询、联合查询、子查询等的复杂查询

3.table:

表示这一行的数据是关于哪张表的。

4.★type（注意结合脑图中的sql语句理解）：

从最好到最次依次如下：
system>const>eq_ref>ref>range>index>ALL
一般，查询优化至少到range，最好能达到ref

4.1.system 忽略不计

4.2.const：表示通过索引一次就找到了,const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快。不过没技术含量，实际意义也较少。
如将主键置于where列表中，MySQL就能将该查询转换为一个常量

4.3.eq_ref： 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描(比如从一堆员工里找到一个ceo)

4.4.ref：非唯一性索引扫描，返回匹配某个单独值的所有行.
本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，
它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体
（找到公司所有员工中的某个程序员）
select * from t1 where col1=‘ac’
与eq_ref一条索引只对应一个值相比，ref一条索引可能对应多个值

4.5. range：只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引
一般就是在你的where语句中出现了between、<、>、in等的查询
这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引

4.6. index：Full Index Scan，index与ALL区别为index类型只遍历索引树。这通常比ALL快，因为索引文件通常比数据文件小。
（也就是说虽然all和Index都是读全表，但index是从索引中读取的，而all是从硬盘中读的）

4.7. ALL：遍历全表去找到匹配的行

5.possible_keys 和 ★key:

1.说明是否使用了索引，索引是否失效
2.多个索引竞争前提下，mysql用的哪个索引

5.1 possible_key:显示可能应用在这张表中的索引，一个或多个。
查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用(理论将要用到的索引)

5.2 key：实际使用的索引。如果为NULL，则没有使用索引
查询中若使用了覆盖索引，则该索引和查询的select字段重叠。

6.key_len:

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。

查的越精确，付出的代价（key_len字节数越大）

7.ref：

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

8.★rows：

rows列显示MySQL认为它执行查询时必须检查（扫描）的行数。–越少越好

9.★Extra：

包含不适合在其他列中显示但十分重要的额外信息。
9.1 ★using filesort： 某种情况下没用到索引，mysql在内部又重新进行了特定排序。（例：没有按照索引顺序写查询，比如把联合索引的中间一个索引遗漏）

9.2：★using temporary：使了用临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。
创建临时表得把数据搬到临时表，用完后回收临时表，效率大大↓。
解决：group by/order by 后的数据，一定要尽量根据索引的个数和顺序保持一致

9.3： ★using index：它出现，说明是好事。
表示相应的select操作中使用了覆盖索引(Covering Index)，避免访问了表的数据行，效率不错！
如果同时出现using where，表明索引被用来执行索引键值的查找;
如果没有同时出现using where，表明索引只是用来读取数据而非利用索引执行查找

9.4： using where： 表明使用了where过滤

9.5：using join buffer：
当涉及join太多，则配置文件中的缓冲的join buffer 可以调大一些。

9.6 ：impossible where：where子句的值总是false，不能用来获取任何元组（比如查名字： where name =‘zhangsan’ and name=‘lisi’ 就为false）

会看以上这些信息，才会去优化，最终把不合适的索引删掉，建立合适索引