Mysql -- 执行计划介绍

一、序言

       作为程序员，难免要和数据库打交道，一般情况下，我们不是DBA ，但是又要写很多SQL，因此SQL效率就成了很大的问题。关于SQL效率优化，除了要掌握一定优化技巧外， 还得有很多经验的积累，但是这里我们可以通过执行计划对SQL进行分析，能快速找到优化的地方，这是一种很不错的方式，介绍给大家，大部分我是翻译而来，原文地址：http://dev.mysql.com/doc/refman/5.6/en/explain-output.html

 

 

二、执行计划输出列的含义：

    

Column Meaning

id	The SELECT identifier
select_type	The SELECT type
table	The table for the output row
partitions	The matching partitions
type	The join type
possible_keys	The possible indexes to choose
key	The index actually chosen
key_len	The length of the chosen key
ref	The columns compared to the index
rows	Estimate of rows to be examined
filtered	Percentage of rows filtered by table condition
Extra	Additional information

 

● id：

   查询的标识，表示在select 执行语句中的顺序（PS：数字越大，优先执行）。如果这行是和其他行合并的结果，这个值可以为null。比如：使用 UNION 关键字，将多个select 的结果合并到一起。

 

● select_type：每个select 的类型。

select_type Meaning

SIMPLE	简单的 SELECT (没有 使用UNION 或者 子查询（PS：单表查询）)
PRIMARY	最外层的Select 作为primary 查询。(PS:含有子查询的情况,但是并不复杂)
UNION	从第二个或者在union 之后的select 作为 union 查询
DEPENDENT UNION	从第二个或者在union 之后的select 作为 union 查询， 依赖于外部查询
UNION RESULT	结果集是通过union 而来的，作为...
SUBQUERY	第一个查询是子查询
DEPENDENT SUBQUERY	第一个查询是子查询，依赖于外部查询
DERIVED	在from 查询语句中的（派生，嵌套很多）子查询.(PS:递归操作这些子查询)
MATERIALIZED	（雾化） 子查询（PS：子查询是个视图？）
UNCACHEABLE SUBQUERY	子查询结果不能被缓存， 而且必须重写（分析）外部查询的每一行
UNCACHEABLE UNION	第二个 或者 在UNION 查询之后的select ,属于不可缓存的查询

 

● Table：输出所用到的表（PS：通过id 联系） 

● Type：连接类型，很重要的分析手段，下面按最优到最差排序：

   System：表只有一行（=系统表），const 的特例

 

   const：表查询结果最多只有一行，因为只有一行，该查询优化部分一般是常数。比如根据主键id=1 查询。

   比如：

SELECT * FROM tbl_name WHERE primary_key=1;

 

 

 

    eq_ref:从当前这个表读出的一行，和前面所有表的行进行组合，这是除了const 和system 外，最好的连接类型，它是用于所有的都是用唯一索引去连接被主键或者不为空的索引。常用=操作符比较索引

    比如：

    

SELECT * FROM ref_table,other_table WHERE ref_table.key_column=other_table.column;

 

 

 

    ref:用于连接非唯一索引的扫描。可以对索引的列使用> = <> 的操作符。

    比如： 

  

 SELECT * FROM ref_table WHERE key_column=expr;
 SELECT * FROM ref_table,other_table WHERE ref_table.key_column=other_table.column;

 

     

 SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

    

     fulltext : 该方式使用的是全文检索


       ref or null : 该连接方式像ref,但是包含null 的值 ，该连接类型主要是解决子查询

       比如：

 

SELECT * FROM ref_table WHERE key_column=expr OR key_column IS NULL;

 

     index_merge:索引合并优化（PS:多个索引条件情况，进行条件的合并优化）

      

我版本低，没出现。。，可以参考下面解释：
http://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html
SELECT * FROM tbl_name WHERE key1 = 10 OR key2 = 20;
SELECT * FROM tbl_name
  WHERE (key1 = 10 OR key2 = 20) AND non_key=30;

SELECT * FROM t1, t2
  WHERE (t1.key1 IN (1,2) OR t1.key2 LIKE 'value%')
  AND t2.key1=t1.some_col;

SELECT * FROM t1, t2
  WHERE t1.key1=1
  AND (t2.key1=t1.some_col OR t2.key2=t1.some_col2);

   

    unique_subquery：这个参照ref,处理子查询

    比如：

value IN (SELECT primary_key FROM single_table WHERE some_expr)

 

   index_subquery：这个和unique_subquery 类似，取代非唯一索引的子查询

    比如：

value IN (SELECT key_column FROM single_table WHERE some_expr)

 

    range:只有在range 范围内的都被检索，只用索引才查询哪些行。后面Key 表示你用的那个索引：

    比如：

    

SELECT * FROM tbl_name
  WHERE key_column = 10;

SELECT * FROM tbl_name
  WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name
  WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name
  WHERE key_part1 = 10 AND key_part2 IN (10,20,30);

    

    index :这索引连接类型和ALL一样，除了树的索引扫描，分为两种情况： 1.会便利索引树，2.没有索引树，就是ALL 一样。

 

     All:全表扫描，通常是最差的一种查询。

 

● Extra：包含mysql 解析查询的额外信息。

   Distinct：mysql 查询不同的行，当找到和当前行匹配的时候，就不再搜索了。

   FirstMatch(tbl_name) ：The semi-join FirstMatch join shortcutting strategy is used for tbl_name.  

   Full scan on NULL key：查询分析器无法使用当前索引的一个失败策略。

   Impossible HAVING： where 条件总是false,无法筛选任何行

   Impossible WHERE noticed after reading const tables：和上面类似

   LooseScan：利用索引来扫描一个子查询表可以从每个子查询的值群组中选出一个单一的值。

   Not exists：mysql 优化了left join 的查询，

   比如：

   

SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id WHERE t2.id IS NULL;

假设t2.id 定义为 not null,这种情况下，Mysql 扫描t1 并且用t1.id 在t2中查找行，如果Mysql 在t2中找到匹配的行，它表明t2.id 不可能为null,因此不会扫描剩下的具有相同id的行，换句话说，t1 中的每一行，mysql 每次都在t2中做一下查询，无论t2 有多少匹配。

   

 

    Using filesort：无法利用索引完成的排序，比如文件排序

    Using index:利用索引树扫描得出结果，不用全部扫描

    Using temporary:利用临时表存储结果集，通常查询包含 GROUP BY and ORDER BY 。

     Using where：使用where 限定那些行于下一张表匹配，或者返回到客户端，除非你想要获取or 检查表中所有行，如果extra 的值不是Using where并且连接类型不是all 或者index ，那么你可能有一些错误在你的查询中。

    Using join buffer：

    Using MRR:有点复杂，

    参考：http://dev.mysql.com/doc/refman/5.6/en/mrr-optimization.html

    和：http://blog.csdn.net/zbszhangbosen/article/details/7463394

 

 

● Key ：key 这一列表明实际你用的是那一个索引，没有则是null

● Key len：该列是Mysql 使用key 的长度，没有则为null,文档提示这值能确定你 multiple-part key  中使用的是哪一部分。

● Rows：表示Mysql 执行语句扫描的行数

● Possible_keys：表示mysql 找到的这些行数据，在indexes(很多索引)里面的哪一个。查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。如果是空的，没有相关的索引。这时要提高性能，可通过检验WHERE子句，看是否引用某些字段，或者检查字段不是适合索引。

 

 

小结：

        1.这个不得不吐槽，翻译太烂了...以至于后面都是自己的理解弄的，建议都去看原文啊，而且5.6+ 变化挺多，有些变化我也没遇到过，请见谅啊。

        2.这些简单的说明呢，仅仅是给大家提供一种分析SQL 的途径，也提醒大家不要盲目的根据SQL 去判断效率，当然你经验丰富，就不说啦~。~新手学习。

        3.如果你需要更详细的可以用show profile 的东西，能看到更详细的信息，精确度也更高，还有关于一些实战方面的应用，没来得及总结，这个以后再介绍吧。

        4.还是请见谅下，不正确的 狗血的地方请指出哦，谢谢啦。

        最后分享个不错的mysql 地址：

        http://www.mysqlab.net/

        http://www.mysqlpub.com/

    

      

评论

2 楼 greemranqq 2014-05-29  

taoshi 写道

5.6+ 才支持呗？

嗯，但是原来的那些也有，只是后面做了更多优化，我发的网址上面 有以前版本的

1 楼 taoshi 2014-05-29  

5.6+ 才支持呗？