MySQL之执行计划

目录

一、MySQL中SQL语句执行过程

二、MySQL优化器及分类

三、执行计划 - Explain

 1.什么是执行计划？

 2.执行计划的作用

  3.执行计划包含的信息

四、正确使用索引

---

一、MySQL中SQL语句执行过程

MySQL中SQL语句执行过程图如下：

文字讲解： 

  1.客户端发送一条查询给服务器。
  2.服务器先检查查询缓存，如果命中了缓存，则立刻返回存储在缓存中的结果。否则进入下一阶段。
  3.服务器端进行SQL解析、预处理，再由优化器生成对应的执行计划。
  4.MySQL根据优化器生成的执行计划，再调用存储引擎的API来执行查询。
  5.将结果返回给客户端。

二、MySQL优化器及分类

传统关系型数据库里面的优化器分为CBO和RBO两种。

 1）RBO--- Rule_Based Potimizer 基于规则的优化器:

  RBO :RBO所用的判断规则是一组内置的规则，这些规则是硬编码在数据库的编码中的，RBO会根据这些规则去从SQL诸多的路径中来选择一条作为执行计划（比如在RBO里面，有这么一条规则：有索引使用索引。那么所有带有索引的表在任何情况下都会走索引）所以，RBO现在被很多数据库抛弃（oracle默认是CBO，但是仍然保留RBO代码，MySQL只有CBO）

      RBO最大问题在于硬编码在数据库里面的一系列固定规则，来决定执行计划。并没有考虑目标SQL中所涉及的对象的实际数量，实际数据的分布情况，这样一旦规则不适用于该SQL，那么很可能选出来的执行计划就不是最优执行计划了。

2）CBO---Cost_Based Potimizer 基于成本的优化器:

      CBO :CBO在会从目标诸多的执行路径中选择一个成本最小的执行路径来作为执行计划。这里的成本他实际代表了MySQL根据相关统计信息计算出来目标SQL对应的步骤的IO，CPU等消耗。也就是意味着数据库里的成本实际上就是对于执行目标SQL所需要IO,CPU等资源的一个估计值。而成本值是根据索引，表，行的统计信息计算出来的。(计算过程比较复杂)    

三、执行计划 - Explain

 1.什么是执行计划？

      使用 EXPLAIN 关键字可以模拟优化器执行SQL查询语句，从而知道MYSQL是如何处理你的sql语句的。分析你的查询语句或是表结构的性能瓶颈。（语法: Explain + sql）

 2.执行计划的作用

     1) 表的读取顺序
     2) 数据读取操作的操作类型
     3) 哪些索引可以使用
     4) 哪些索引被实际使用
     5) 表之间的引用
     6) 每张表有多少行被优化器查  

  3.执行计划包含的信息

   3.1 id - 获取select子句的操作表顺序，有几种情况

     1) id 相同的情况下执行顺序是由上到下。
     2) id 越大优先级越高，如果是子查询，ID 序列号会递增，id值越大，优先级越高，越先执行。
     3) id 相同又有不相同的，序列号大的会先执行，然后相同的从上到下执行。

示例： 

#1）id相同，从上往下一次执行
#左外联
explain select * from t_user t1 left join t_role t2 on t1.roleid = t2.roleid;

#右外联
explain select * from t_role t1 right join t_user t2 on t1.roleid = t2.roleid;

 左外联

 右外联

 注意：通过left join 和 right join 验证；id一样（注意执行计划的table列），left join 先扫描a表，再扫描b表；right join 先扫描b表，再扫描a表

3.2 select_type - 查询的类别，主要用于区别普通查询，联合查询，子查询等的复杂查询

     1) simple: 简单的select 查询，不包含子查询或者 union
     2) primary: 查询中包含任何复杂的子部分，最外层查询则被标记
     3) subquery: 在 select 或者 where 列表中包含了子查询
     4) derived: 在from 列表中包含子查询被标记为 derived Mysql 会递归执行这些子查询，把结果放到临时表里
     5) union: 若在第二个 select 中出现 union之后，则被标记为 union 若union包含在 from 子句的子查询中，外层 select 将被标记为 derived
     6) union result: 从 union 表获取结果的 SELECT

示例：

• SIMPLE(简单SELECT,不使用UNION或子查询等)

explain select * from t_user where username = '张三';

•  PRIMARY(查询中若包含任何复杂的子部分,最外层的select被标记为PRIMARY)SUBQUERY(子查询中的第一个SELECT)

explain select * from t_user t1 where t1.roleid = (select roleid from t_role t2 where t2.roleid = 1);

•  UNION(UNION中的第二个或后面的SELECT语句)

explain
select * from t_user t1 where t1.id = 1 
union all
select * from t_user t2 where t2.id = 2;

•  DERIVED(派生/衍生表的SELECT, FROM子句的子查询)

explain select tmp.* from (
	select * from t_user t1 where t1.id = 1 
	union all
	select * from t_user t2 where t2.id = 2
) tmp;

 

 3.3 table - 显示这一行的数据是关于那个表的

 3.4 type - 显示的是访问类型 

type是较为重要的一个指标，结果值从最好到最坏依次是：（ 注：一般来说，得保证查询至少达到range级别，最好能达到ref）

  system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery 
     > index_subquery > range > index > all

    1) system: 表中只有一行记录（等于系统表），这是const类型的特列，平时不会出现，这个可以忽略不计;
     2) const:  表示通过索引一次就找到了，const用于比较primary key或者unqiue索引，因为只匹配一条数据，所以很快，如将主键置于where条件中，Mysql 就能将该查询转换一个常量;
     3) eq_ref: 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配，常见与主键或唯一索引扫描;
     4) ref:    非唯一索引扫描，返回匹配某个单独值的所有行，常见于使用非唯一索查询，组合索引查询;
     5) range:  只检索给定范围的行，使用一个索引来选择行，key列显示使用了哪个索引， 一般就是在你的 where 语句中出现了 between ,<,>,in 等查询这种范围扫描比全表扫描要好， 因为它只需要开始与索引的某一点，而结束与另一点，不用扫描全部索引。
     6) ALL：   全表扫描;
     7) index： 扫描全部索引树;
     8) NULL：  MySQL在优化过程中分解语句，执行时甚至不用访问表或索引;

   3.5 possible_keys

    指出MySQL能使用哪个索引在该表中找到行。查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。如果是空的，没有相关的索引。这时要提高性能，可通过检验WHERE子句，看是否引用某些字段，或者检查字段不是适合索引。（简而言之：可能使用的key（索引））

3.6 key 

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

3.7 key_len

    显示MySQL决定使用的键长度。表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。如果键是NULL，长度就是NULL。文档提示特别注意这个值可以得出一个多重主键里mysql实际使用了哪一部分。

3.8 ref

显示哪个字段或常数与key一起被使用
3.9 rows

     这个数表示mysql要遍历多少数据才能找到，表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数，在innodb上可能是不准确的。

3.10 Extra

包含不合适在其他列中显示但十分重要的额外信息：

     1) Using index    此值表示mysql将使用覆盖索引，以避免访问表。
     2) Using where    mysql 将在存储引擎检索行后再进行过滤，许多where条件里涉及索引中的列，当(并且如果)它读取索引时，就能被存储引擎检验，因此不是所有带where子句的查询都会显示“Using where”。有时“Using where”的出现就是一个暗示：查询可受益于不同的索引。
     3) Using temporary    mysql 对查询结果排序时会使用临时表。
     4) Using filesort    mysql会对结果使用一个外部索引排序，而不是按索引次序从表里读取行。mysql有两种文件排序算法，这两种排序方式都可以在内存或者磁盘上完成，explain不会告诉你mysql将使用哪一种文件排序，也不会告诉你排序会在内存里还是磁盘上完成。

四、正确使用索引

示例一：使用like语句时，%在右边才会使用索引

#有效
explain select * from t_user t where t.username like '张%';

#无效
explain select * from t_user t where t.username like '%张%';

前：有效   后：无效

 

示例二：or条件中有未建立索引的列才索引失效

#有效
explain select * from t_user t where t.username = '张三' and id =1;

#无效
explain select * from t_user t where t.username = '张三' or id = 1;

前：有效   后：无效

示例三： 条件的类型不一致

#有效
explain select * from t_user t where t.username = '12345';

#无效
explain select * from t_user t where t.username = 12345;

 前：有效   后：无效

 

 示例四：!= 号（例外：如果是主键，则会走索引）

#无效
explain select * from t_user t where t.username != '张三';
#有效
explain select * from t_user t where t.id != 1; 

explain select * from t_user t where t.id in (1,2,3);

根据上方代码查看

 示例五：组合索引（遵循最左前缀）

#有效
explain select * from t_user t where t.username like '李%' and t.idcard = '430104200111134321';
#无效
explain select * from t_user t where t.username like '李%';

有效