最近学习MySQL的高级应用Explain，写一篇学习心得与总结，目录脑图如下：
在这里插入图片描述

一、Explain基本概念

1. Explain定义

· 我们知道MySQL中有一个查询优化器Query Optimizer，它的作用是找到最小代价的正确执行方案；

· EXPLAIN :模拟Mysql优化器是如何执行SQL查询语句的，从而知道Mysql是如何处理你的SQL语句的，分析你的查询语句或是表结构的性能瓶颈。

· explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。

2. Explain的作用

通过在select+sql语句前加上explain，我们可以看出：
（1）表的读取顺序，id（table是id对应的表）
（2）数据读取操作的操作类型，select type
（3）哪些索引可以使用，possible_keys
（4）哪些索引被实际使用，key
（5）表之间的引用，ref
（6）每张表有多少行被优化器查询，rows

3. explain执行计划包含的信息

在这里插入图片描述

二、Explain中各字段的解释

1. id

select查询的数字序列号，表示查询中执行select子句、或多表联合查询时操作表、的顺序；
· （1）id相同，执行顺序由上至下
在这里插入图片描述
从t1、t2、t3三张表中查询t2表的全部，查询条件是：t1.id=t2.id 、t1.id=t3.id、t1的其他字段是空；
优化器对于同一个where内部的条件，默认是从右往左读取的；
所以三张表的执行顺序是：t1 -> t3 -> t2；

· （2）id不同，id越大执行优先级越高
如果是子查询，id的序列号会递增，越是在里面的子查询越优先执行，类似于递归的思想；( )里的语句具有优先级
在这里插入图片描述
从t2表中查询t2表的全部，查询条件是id，查询条件是三层嵌套：
从表t1查询id——id是从表t3中查询到的t3表的id——t3表的其他字段为空；
用递归的思想，很容易判断，表的执行顺序：t3 -> t1 -> t2

· （3）id同时存在相同和不同的情况，id不同的id大的优先执行，id相同的从上到下执行
在这里插入图片描述
这里需要引入一个概念，衍生虚表查询（Derived）：
从原表中截取部分信息，组成的结果集可以构成一张新表，这张表并不实际存在，作为一张虚表被调用；这种查询就叫衍生虚表查询；

（从表t3中查询t3表的id，查询条件是其他字段为空）将括号中t3表的查询条件，的结果集作为一张虚表s1，
从虚表s1、表t2中，查询表t2的全部，查询条件是s1.id=t2.id；
所以，查询的顺序是：t3 -> derived2 -> t2
derived2指，由id=2时，即表t3的结果集衍生构成的虚表s1；

2. select_type

查询的类型，一共有以下6种表的查询类型：

· （1）SIMPLE
简单查询，查询中不包含子查询、union（联合查询）；

· （2）PRIMARY
查询中若包含子查询，则最外层查询被标记为PRIMARY；

· （3）SUBQUERY
在select或where列表中的子查询

· （4）DERIVED
典型语法：from ( 子查询 ) s1，
在from列表中包含的子查询，被标记为DERIVED（衍生），这个子查询执行后的结果集放在一张虚表s1中；

· （5）UNION
若第二条select出现在union之后，则标记为union联合多表查询；
若union包含在from字句的查询中，即select 属性 from（子查询1 union 子查询2）s1，这种外层的select被标记为DERIVED；

· （6）UNION RESULT
从UNION表中获取结果的SELECT

3. table

指id对应的表，通过id判断表的执行顺序；
也指这一行的数据是关于哪张表的；

4. type

显示查询时，使用了哪种查询类型，日常工作中经常接触到的有以下7种，性能由最好到最差依次是：
system > const > eq_ref > ref > range > index > ALL
一般需要保证查询类型等级达到range，最好能达到ref，避免使用ALL。

· （1）system
系统查询，指表中只有一行数据，这是const的特例，平时不会出现，因为只有一行信息就不叫大数据了，所以意义不大；

· （2）const
常量查询，表示通过索引Index一次就找到了，用于比较 primary key=常量和 unique=常量这种索引；
如将主键置于where列表中，mysql具有自动转换类型的功能，会自动将该查询转化为一个常量
在这里插入图片描述
d1是虚表，括号具有优先级，首先执行表t1，where id = 1是常量查询const；
虚表d1由于只有一行数据，所以查询类型是系统查询system；

· （3）eq_ref
唯一性索引扫描，对于每个索引键，表中只对应一行数据，常见于主键
在这里插入图片描述
where后面没有括号，MySQL优化器从左到右执行，因此先执行表t2，type是ALL全表查询，对应639行信息；然后查询表
t1，type是eq_ref，表1中id只对应1行信息，唯一索引扫描；

· （4）ref
非唯一索引扫描，对于每个索引键，表中可能对应多行数据；
在这里插入图片描述
查询表t1中，不重复的字段col1有7条，其余全是重复的；
满足查询条件col1='ac’的记录有284行，所以是ref非唯一索引扫描；

· （5）range
范围查询，where后面的列表中是between、<、>、in等的查询；
在这里插入图片描述
关键词between，type是range范围查找；

关键词in，type是range范围查找；
★ 关键词like也是范围查找，后面再写；

· （6）index
全索引扫描，FULL INDEX SCAN，只遍历索引树，通常比ALL快；
（index与ALL都是全表查询，但index是从索引中读取，ALL是从全表中读取）；

· （7）ALL
全表扫描，FULL TABLE SCAN，遍历全表找到匹配的行；速度最慢，避免使用；

5. possible_keys

查询的字段上若存在索引，则将索引列出，一个或多个，但不一定在查询时实际使用；

6. key

实际使用的索引，若为NULL，则没有使用索引，常见的可能原因：
· （1）没有建索引
· （2）sql语句写法错误，索引失效；
· （3）possible_key也为NULL时，表示用不到索引

7. key_len

可以通过key_len看出索引字段的个数，74指1个，78指2个，140指3个；

8. ref

显示使用索引的是哪个字段，可以是一个const常量；
ps：type里的ref指非唯一索引扫描，对索引字段，可能存在多个重复值；
在这里插入图片描述
从表t1和表t2中查询所有，查询条件：t1.col1=t2.col1、t1.col2=‘ac’;
同一个where列表中，优化器从右到左执行，索引有两个字段；
优先执行字段值’ac’，是const常量；
然后执行数据库shared中表t2中的字段col1，即shared.t2.col1；

9. rows

索引查询时，大致估算出查询到所需记录读取的行数，rows越小越好；

10. Extra

额外信息，包含以下三种：
· （1）Using filesort
说明建立的、准备使用的索引index并没有被用到，执行了文件排序；
可能是sql语句写法有问题，与之前建立的索引index冲突了；

· （2）Using temporary
使用了临时表来保存中间结果，说明建立的索引没有使用完全；
常见于排序order by和分组查询group by；

· （3）Using index
select操作中用到了覆盖索引（Covering Index），说明sql执行的效率不错！
覆盖索引（Covering Index）：
eg：先creat一个index，index_字段a_字段b；
然后select 字段a，字段b on table where 字段a=…，字段b=…
即先创建拥有某几个字段的索引，然后查询索引里的字段，where列表是索引字段的值；即当索引字段值为XXX时，查询该字段；这是select效率最高的方式。
··· 若同时出现using where，表明索引被用来执行索引键值的查找；
··· 若没有同时出现using where，表明索引没有用来执行索引键值的查找，只是用来读取数据；

三、Explain中优化索引心得总结

1. 左前缀保留原则

如果索引了多个字段，查询从索引的最左端字段开始，并且不会跳过索引中的字段；
eg：索引字段1，2，3，对应楼层的123层，
如果没有1层，索引2和3，那么无法找到2楼和3楼；
如果没有中间层2层，那么无法找到3楼；

ALTER TABLE staffs ADD INDEX idx_staffs_nameAgePos(name, age, pos);

在这里插入图片描述
创建索引 idx_staffs_nameAgePos(name, age, pos)，索引字段从左往右依次是name、age、pos
从上图中可以看出：
表1和表2没有name，所以索引无法查找，possible_keys和key都是NULL，出错；
表3中有name，possible_keys和key使用索引idx_staffs_nameAgePos查询，正确；

2. 不在索引列上做任何操作（计算、函数、（自动or手动）类型转换）

已经建立好了索引，在select时，在where列表中对索引列表进行修改，容易引起索引失效，从而变成全表扫描ALL，
降低数据库的效能；

3. 存储引擎不能使用索引中范围条件range（<、>、between、in等）右边的索引字段

在这里插入图片描述
最下面的索引，age>11是范围条件，它右边的字段pos='manger’索引失效；
所以最后索引只用到了两个字段，name和age；key_len是78；

4. like形式的range范围查询，以通配符%开头时，要将%放在字母右边，否则索引失效转为全表扫描

在这里插入图片描述
可以发现，当like后面字段通配符%放在最左边时，索引失效，type转为全表扫描ALL；
因为字段扫描时，%在最左边无法确定字段，所以索引失效；
若字母在字段最左边，可以确定字段，索引有效；

5. 尽量使用覆盖索引（Covering Index），即create的索引字段与select中where列表的查询字段，一致；

减少使用select *，提高索引效率；

6. 使用不等于（!=、<、>）时，有时无法使用索引会导致全表扫描ALL

在这里插入图片描述
* 原本的name='July’时，使用的查询类型type是ref非唯一性索引；*
当变成!=和<>后，转为全表扫描ALL，索引失效；

7. 在创建table中数据时，字段的null/not null，要与explain select where列表中字段保持一致

eg：创建表时，插入数据，字段a为null；
explain select where列表中字段a not null；
查询会出问题；

8. 字符串不加单引号，索引会失效

在这里插入图片描述
name=‘917’，变成了name=917；优化器自动转换字段的类型，结果索引失效，key为NULL；

9. 少用or，用它来连接时，索引会失效