Read the MySQL execution plan
Source: Self-recommended by Ju Qian
www.andyqian.com/2017/11/01/database/MySQLplain/
If you have a good article to contribute, please click → here for details
foreword
In the previous interview process, when asked about the execution plan, many children's shoes did not know what it was? Even the execution plan and the execution time were regarded as the same concept. Today, let's take a look at what is the execution plan? What is the use?
What is the execution plan?
The execution plan, in simple terms, is the performance of SQL when it is executed in the database, and is usually used in scenarios such as SQL performance analysis and optimization. Use the explain keyword in MySQL to view the SQL execution plan. As follows:
//1. Query t_base_user
select *from t_base_user wherename="andyqian";
//2. View the execution plan of the above statement
explain select *from t_base_user wherename="andyqian";
After executing and viewing the above 2 statements, we can get the following execution plan results
What does the execution plan above mean? What is the reference value?
The information given by the above execution plan is: This result is filtered through a simple statement full table scan, scanning 1 row in total, and using the where condition to filter out the t_base_user table. It is found that the statement does not go to the index, why is this? Don't worry, let's move on to the next section.
Read the execution plan
Through the above, we know what an execution plan is, and we have also seen what an execution plan is. Now let's take a look at what each attribute represents in the MySQL execution plan.
Let's introduce them one by one, and explain what optional values each attribute has and what each optional value means.
-
id
indicates the order of the select operation table in the query, which is executed in order from largest to largest -
select_type :
该表示选择的类型,可选值有: SIMPLE(简单的), -
type :
该属性表示访问类型,有很多种访问类型。
最常见的其中包括以下几种: ALL(全表扫描), index(索引扫描),range(范围扫描),ref (非唯一索引扫描),eq_ref(唯一索引扫描,),(const)常数引用, 访问速度依次由慢到快。其中 : range(范围)常见与 between and …, 大于 and 小于这种情况。
提示 : 慢SQL是否走索引,走了什么索引,也就可以通过该属性查看了。 -
table :
表示该语句查询的表 -
possible_keys :
顾名思义,该属性给出了,该查询语句,可能走的索引,(如某些字段上索引的名字)这里提供的只是参考,而不是实际走的索引,也就导致会有possible_Keys不为null,key为空的现象。 -
key :
显示MySQL实际使用的索引,其中就包括主键索引(PRIMARY),或者自建索引的名字。 -
key_len :
表示索引所使用的字节数， -
ref :
连接匹配条件,如果走主键索引的话,该值为: const, 全表扫描的话,为null值 -
rows :
扫描行数,也就是说，需要扫描多少行,采能获取目标行数,一般情况下会大于返回行数。通常情况下,rows越小,效率越高, 也就有大部分SQL优化，都是在减少这个值的大小。注意: 理想情况下扫描的行数与实际返回行数理论上是一致的,但这种情况及其少,如关联查询,扫描的行数就会比返回行数大大增加) -
Extra
这个属性非常重要,该属性中包括执行SQL时的真实情况信息,如上面所属,使用到的是”using where”，表示使用where筛选得到的值,常用的有:
“Using temporary”: 使用临时表 “using filesort”: 使用文件排序
看到这里,我们应该已经发现,在第一步中,我们的这条SQL
select * from t_base_user where name="andyqian";
是没有走索引的,而且还是全表扫描,在数据量少的情况下,问题还不会特别突出,如果数据量比较大,这可是个会造成生产事故的慢查询哦，现在我们改造一下,将name字段添加上索引,
# 添加索引
alter table t_base_user add index idx_name(name);
看看它的执行计划是怎样的。
你看,现在已经走idx_name索引了,其type从All(全表扫描)到ref(非唯一索引了)，别看就只有这一点点小区别,在大数据量的时候,可是会起大作用的哦。
数据结
本文中演示的数据结构如下:
# 创建表
create table t_base_user(
oid bigint(20) not null primary key auto_increment,
name varchar(30) null comment "name",
email varchar(30) null comment "email",
age int null comment "age",
telephone varchar(30) null comment "telephone",
status tinyint(4) null comment "0 无效 1 有效",
created_at datetime null comment "",
updated_at datetime null comment ""
)
## 新增记录:
insert into t_base_user(name,email,age,telephone,created_at,updated_at)values("andyqian","[email protected]",20,"15608411",now(),now());
)
最后
一个好的数据库表设计,从一开始就应该考虑添加索引,而不是到最后发现慢SQL了,影响业务了,才来补救。其实我在工作经历当中，由于新建表,或新加字段后,忘记添加索引也造成了多次生产事故,记忆犹新!!!
其实新建索引也是有一定的原则的,建什么索引,建在哪些字段上,这里面还有不少知识呢，下一篇文章写,尽请期待吧!