Explain的简述

使用Explain关键字，可以了解MySql如何使用索引来处理SELECT语句以及连接表。可以帮助我们选择更好的索引和写出更优化的查询语句。

通过EXPLAIN我们可以得到一下结果：

  • 表的读取顺序
  • 数据读取操作的操作类型
  • 哪些索引可以使用
  • 哪些索引被实际使用
  • 表之间的引用
  • 每张表有多少行被优化器查询

Explain结果详述

使用方式

  1. --explain关键字 + sql语句 --
  2. EXPLAIN SELECT * FROM tableName

得到的执行计划：
image.png

执行计划个字段介绍

id

select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序。

  1. --t1,t2,t3表结构相同--
  2. CREATE TABLE `t3` (
  3.   `id` int(11) NOT NULL,
  4.   `name` varchar(20) DEFAULT NULL,
  5.   PRIMARY KEY (`id`)
  6. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  7. --（1）执行该语句时的结果，id值相同，执行顺序由上至下 --
  8. EXPLAIN SELECT t2.* 
  9. FROM t1,t2,t3 
  10. WHERE
  11.     t1.id = t2.id 
  12.     AND t1.id = t3.id 
  13.     AND t1.NAME = 'tom'
  14. --（2）执行该语句的结果，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行--
  15. EXPLAIN SELECT t2.*
  16. from t2 where id=(
  17.   select id from t1 where id=(
  18.     select t3.id from t3 where t3.name='rose'))
  19. --（3）id相同不同，同时存在，相同时从上往下执行，不同时id越大优先级越高，越先执行 --

第一种情况： image.png 第二种情况： image.png

select_type

顾名思义，select_type用来表示查询的类型，主要是用于区别普通查询、联合查询、子查询等的复杂查询。

  • SIMPLE 简单的select查询，查询中不包含子查询或者UNION
  • PRIMARY 查询中若包含任何复杂的子部分，最外层查询则被标记为PRIMARY
  • SUBQUERY 在SELECT或WHERE列表中包含了子查询
  • DERIVED 在FROM列表中包含的子查询被标记为DERIVED（衍生），MySQL会递归执行这些子查询，把结果放在临时表中
  • UNION 若第二个SELECT出现在UNION之后，则被标记为UNION：若UNION包含在FROM子句的子查询中，外层SELECT将被标记为：DERIVED
  • UNION RESULT 从UNION表获取结果的SELECT

table

table表示当前执行的表

type

type所显示的是查询使用了哪种类型，type包含的类型及顺序：

system > const > eq_ref > ref > range > index > all
一般来说，得保证查询至少达到range级别，最好能达到ref。

  • system 表只有一行记录（等于系统表），这是const类型的特列，平时不会出现，这个也可以忽略不计
  • const 表示通过索引一次就找到了，const用于比较primary key 或者unique索引。因为只匹配一行数据，所以很快。如将主键置于where列表中，MySQL就能将该查询转换为一个常量。
  • eq_ref 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描
  • ref 非唯一性索引扫描，返回匹配某个单独值的所有行，本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体。
  • range 只检索给定范围的行，使用一个索引来选择行，key列显示使用了哪个索引，一般就是在你的where语句中出现between、< 、>、in等的查询，这种范围扫描索引比全表扫描要好，因为它只需要开始于索引的某一点，而结束于另一点，不用扫描全部索引。
  • index Full Index Scan，Index与All区别为index类型只遍历索引树。这通常比ALL快，因为索引文件通常比数据文件小。（也就是说虽然all和Index都是读全表，但index是从索引中读取的，而all是从硬盘读取的）
  • all Full Table Scan 将遍历全表以找到匹配的行

    possible_keys 和 key

    possible_keys：显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用。 key：实际使用的索引，如果为NULL，则没有使用索引。（可能原因包括没有建立索引或索引失效）；查询中若使用了覆盖索引（select 后要查询的字段刚好和创建的索引字段完全相同），则该索引仅出现在key列表中

key_len

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度，在不损失精确性的情况下，长度越短越好。key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的。

ref

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

rows

根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数，也就是说，用的越少越好

Extra

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

  • Using filesort：说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成的排序操作称为“文件排序”。
  • Using temporary：使用了用临时表保存中间结果，MySQL在对查询结果排序时使用临时表。常见于排序order by和分组查询group by。
  • Using Index：示相应的select操作中使用了覆盖索引（Covering Index），避免访问了表的数据行，效率不错。如果同时出现using where，表明索引被用来执行索引键值的查找；如果没有同时出现using where，表明索引用来读取数据而非执行查找动作。
  • Using where ：表明使用了where查询。
  • Using join buffer ：表明使用了连接缓存,比如说在查询的时候，多表join的次数非常多，那么将配置文件中的缓冲区的join buffer调大一些。
  • impossible where ：where子句的值总是false，不能用来获取任何元组
  • select tables optimized away：在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。
  • distinct：优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作

覆盖索引

理解方式：select的数据列只需要从索引中就能够获得，不必读取数据行，这样MySql可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件，也就是我们经常说的查询列要被建立的索引覆盖。
当然使用覆盖索引，需要注意的是 select选取列时，只取出需要的列，同时也要避免全字段建立索引，这样会导致索引文件过大反而降低了查询性能。

例子分析

新建一个表test_index_sequence，字段有四个，建立复合索引，验证索引字段的使用顺序对复合索引有效性的影响。
表中数据：
image.png

  1. CREATE TABLE `test_index_sequence` (
  2.     `Id` INT ( 11 ) NOT NULL AUTO_INCREMENT,
  3.     `index_A` VARCHAR ( 255 ) DEFAULT NULL,
  4.     `index_B` VARCHAR ( 255 ) DEFAULT NULL,
  5.     `index_C` VARCHAR ( 255 ) DEFAULT NULL,
  6.     `field_D` VARCHAR ( 255 ) DEFAULT NULL,
  7.     PRIMARY KEY ( `Id` ),
  8. KEY `complex_index` ( `index_A`, `index_B`, `index_C` ) 
  9. ) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8;
  10. ----------单独 查询A列-------------
  11. --索引有效--
  12. EXPLAIN select index_A,index_B,index_C FROM test_index_sequence WHERE index_A='a'
  13. --索引无效--
  14. EXPLAIN select index_A,index_B,index_C,field_D FROM test_index_sequence WHERE index_A='a'
  16. ----------单独 查询B列-------------
  17. --索引有效--
  18. EXPLAIN select index_A,index_B,index_C FROM test_index_sequence WHERE index_B='b'
  19. --索引无效--
  20. EXPLAIN select index_A,index_B,index_C,field_D FROM test_index_sequence WHERE index_B='b'
  22. ----------单独 查询C列-------------
  23. --索引有效--
  24. EXPLAIN select index_A,index_B,index_C FROM test_index_sequence WHERE index_C='c'
  25. --索引无效--
  26. EXPLAIN select index_A,index_B,index_C,field_D FROM test_index_sequence WHERE index_C='c'
  27. ----------联合使用字段index_A,index_B-------------
  28. --索引有效--
  29. EXPLAIN select index_A,index_B,index_C FROM test_index_sequence WHERE index_A='a' AND index_B='b'
  30. --索引有效--
  31. EXPLAIN select index_A,index_B,index_C,field_D FROM test_index_sequence WHERE index_A='a' AND index_B='b'
  33. ----------联合使用字段index_A,index_C-------------
  34. --索引有效--
  35. EXPLAIN select index_A,index_B,index_C FROM test_index_sequence WHERE index_A='a' AND index_C='c'
  36. --索引有效--
  37. EXPLAIN select index_A,index_B,index_C,field_D FROM test_index_sequence WHERE index_A='a' AND index_C='c'
  39. ----------联合使用字段index_B,index_C-------------
  40. --索引有效--
  41. EXPLAIN select index_A,index_B,index_C FROM test_index_sequence WHERE index_B='b' AND index_C='c'
  42. --索引无效--
  43. EXPLAIN select index_A,index_B,index_C,field_D FROM test_index_sequence WHERE index_B='b' AND index_C='c'