一文带你看懂MySQL执行计划

目录
  • 前言
  • explain/desc 用法
  • explain/desc 输出详解
    • 一、id ,select 查询序列号
    • 二、select_type,查询语句类型
    • 三、table,查询涉及的表或衍生表
    • 四、partitions查询涉及到的分区
    • 五、type提供了判断查询是否高效的重要依据依据
    • 六、possible_keys:指示MySQL可以从中选择查找此表中的行的索引。
    • 七、key:MySQL查询实际使用到的索引。
    • 八、key_len:表示索引中使用的字节数(只计算利用索引作为index key的索引长度,不包括用于group by/order by的索引长度)
    • 九、ref:显示该表的索引字段关联了哪张表的哪个字段
    • 十、rows:根据表统计信息及选用情况,大致估算出找到所需的记录或所需读取的行数,数值越小越好
    • 十一、filtered:返回结果的行数占读取行数的百分比,值越大越好
    • 十二、extra:包含不适合在其他列中显示但十分重要的额外信息。常见的值如下
  • 小结:
  • 总结

前言

项目开发中,性能是我们比较关注的问题,特别是数据库的性能;作为一个开发,经常和SQL语句打交道,想要写出合格的SQL语句,我们需要了解SQL语句在数据库中是如何扫描表、如何使用索引的;

MySQL提供explain/desc命令输出执行计划,我们通过执行计划优化SQL语句。

下面我们以MySQL5.7为例了解一下执行计划:

注:文中涉及到的表结构、sql语句只是为了理解explain/desc执行计划,有不合理之处勿喷

explain/desc 用法

只需要在我们的查询语句前加explain/desc即可

准备数据表

-- 创建user表
create table user(
    id int,
    name varchar(20),
    role_id int,
    primary key(id)
)engine=innodb default charset=utf8;
-- 创建role表
create table role(
    id int,
    name varchar(20),
    primary key(id)
)engine=innodb default charset=utf8;

查询,执行计划

 explain select * from user;

执行计划输出有id、select_type、table、partitions、type、possible_keys、key、key_len、ref、rows、filtered、extra,这些内容有什么意义,下面简单介绍一下

explain/desc 输出详解

一、id ,select 查询序列号

1 id相同,从上往下一次执行;

-- 左关联
explain select * from user a left join user b on a.id=b.id;
-- 右关联
explain select * from user a right join user b on a.id=b.id;

通过left join 和 right join 验证;id一样(注意执行计划的table列),left join 先扫描a表,再扫描b表;rightjoin 先扫描b表,再扫描a表

2 id不同,id越大优先级越高,越先被执行

desc select * from user where role_id=(select id from role where name='开发');

我们编写查询角色为开发的用户;可以知道先查询角色name为开发角色id,查询序列号为2;再根据角色id查询用户,查询序列号为1;

二、select_type,查询语句类型

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

explain select * from user;

(2)PRIMARY(查询中若包含任何复杂的子部分,最外层的select被标记为PRIMARY)

 desc select * from user where role_id=(select id from role where name='开发');

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

desc select * from user where name='Java' union select * from user where role_id=1;

(4)DEPENDENT UNION(UNION中的第二个或后面的SELECT语句,取决于外面的查询)

desc select * from user a
     where id in (
         select b.id from user b where b.id=a.id union
         select c.id from role c where c.id=a.role_id
     );

(5)UNION RESULT(UNION的结果)

desc select * from user where name='Java' union select * from user where role_id=1;

(6)SUBQUERY(子查询中的第一个SELECT)

 desc select * from user where role_id=(select id from role where name='开发');

(7)DEPENDENT SUBQUERY(子查询中的第一个SELECT,取决于外面的查询)

desc select * from user where role_id = ( select id from role where id=user.id );

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

desc select * from ( select * from user where name='Java' union select * from user where role_id=1 ) a;

(9) MATERIALIZED(物化子查询) 在SQL执行过程中,第一次需要子查询结果时执行子查询并将子查询的结果保存为临时表 ,后续对子查询结果集的访问将直接通过临时表获得。

(10)UNCACHEABLE SUBQUERY(一个子查询的结果不能被缓存,必须重新评估外链接的第一行)

(11)UNCACHEABLE UNION(UNION查询的结果不能被缓存)

三、table,查询涉及的表或衍生表

table分别user、role表

四、partitions查询涉及到的分区

创建分区表,

-- 创建分区表,
-- 按照id分区,id<100 p0分区,其他p1分区
create table user_partitions (id int auto_increment,
    name varchar(12),primary key(id))
    partition by range(id)(
        partition p0 values less than(100),
        partition p1 values less than maxvalue
    );

desc select * from user_partitions where id>200;

查询id大于200(200>100,p1分区)的记录,查看执行计划,partitions是p1,符合我们的分区规则

五、type提供了判断查询是否高效的重要依据依据

通过type字段, 我们判断此次查询是全表扫描还是索引扫描等,下面简单介绍一下常用的type;

(1)system: 表中只有一条数据,相当于系统表; 这个类型是特殊的const类型;

(2)const:主键或者唯一索引的常量查询,表格最多只有1行记录符合查询,通常const使用到主键或者唯一索引进行定值查询。

主键

-- 创建user表
create table user(id int primary key, name varchar(20), role_id int );
-- 插入一条记录
insert into user values (1, 'a', 1 );
-- 按id查询
desc select * from user where id=1;
-- 按role_id查询
desc select * from user where role_id=1;

分别查看按id和按role_id查询的执行计划;发现按主键id查询,执行计划type为const

将主键设置为id和role_id

-- 删除主键
alter table user drop primary key;
-- 设置主键id,role_id
alter table user add primary key(id,role_id);
-- 按照部分主键查询
desc select * from user where id=1;
-- 按照部分主键查询
desc select * from user where role_id=1;
-- 按照全部主键查询
desc select * from user where id=1 and role_id=1;

发现只有按照全部主键查询,执行计划type为const

唯一索引

-- 删除主键
alter table user drop primary key;
-- 设置主键
alter table user add primary key(id);
-- 设置role_id为唯一索引
alter table user add unique key uk_role(role_id);
-- 按照唯一索引查询
desc select * from user where role_id=1;

发现按role_id唯一索引查询;执行计划type为const

普通索引

-- 将role_id设置成普通索引
-- 删除唯一索引
alter table user drop index uk_role;
-- 设置普通索引
alter table user add index index_role(role_id);
-- 按照普通索引查询
desc select * from user where role_id=1;

发现按role_id普通索引查询;执行计划type为ref

const用于主键或唯一索引查询;将PRIMARY KEY或UNIQUE索引的所有部分与常量值进行比较时使用;与索引类型有关。

(3)eq_ref: 除了system和const类型之外,效率最高的连接类型;唯一索引扫描,对于每个索引键,表中只有一条记录与之对应;常用于主键或唯一索引扫描

准备数据

-- 创建teacher表
create table teacher( id int primary key, name varchar(20), tc_id int );
-- 插入3条数据
insert into teacher values (1,'a',1),(2,'b',2),(3,'c',3);
-- 创建teacher_card表
create table teacher_card( id int primary key, remark varchar(20) );
-- 插入2条数据
insert into teacher_card values (1,'aa'),(2,'bb');
-- 关联查询,执行计划
desc select * from teacher t  join  teacher_card tc on t.tc_id=tc.id  where t.name='a';

执行计划

根据上面的知识;可知id相同,由上至下依次执行,分析结果可知:

先查询t表就是teacher表中name字段为a的记录,由于name字段没有索引,所以全表扫描(type:ALL),一共有3条记录,扫描了3行(rows:3),1条符合条件(filtered:33.33 1/3);

再查询tc即teacher_card表使用主键和之前的t.tc_id关联;由于是关联查询,并且是通过唯一索引(主键)进行查询,仅能返回1或0条记录,所以type为eq_ref。

 -- 删除teacher_card主键
 alter table teacher_card drop primary key;
 -- 这是teacher_card.id为唯一索引
 alter table teacher_card add unique key ui_id(id);
 -- 关联查询,执行计划
 desc select * from teacher t  join  teacher_card tc on t.tc_id=tc.id  where t.name='a';

分析结果,将teacher_card的id设置为唯一索引,type为eq_ref;满足仅能返回1或0条记录。

 -- 删除teacher_card唯一索引
 alter table teacher_card drop index ui_id;
 -- 设置teacher_card.id为普通索引
 alter table teacher_card add index index_id(id);
 -- 关联查询,执行计划
 desc select * from teacher t  join  teacher_card tc on t.tc_id=tc.id  where t.name='a';

分析结果,将teacher_card的id设置为普通索引,type为ref;不满足仅能返回1或0条记录。

equ_ref用于唯一索引查询,对每个索引键,表中只有一条或零条记录与之匹配。

(4)ref:此类型通常出现在多表的 join 查询, 针对于非唯一或非主键索引, 或者是使用了最左前缀规则索引的查询(换句话说,连接不能基于键值选择单行,可能是多行)。

 -- teacher.tc_id无索引,执行计划
 desc select * from teacher t  join  teacher_card tc on t.tc_id=tc.id  where tc.remark='aa';
 -- 设置teacher.tc_id为普通索引
 alter table teacher add index index_tcid(tc_id);
 -- teacher.tc_id有索引,执行计划
 desc select * from teacher t  join  teacher_card tc on t.tc_id=tc.id  where tc.remark='aa';

先查询tc表就是teacher_card表中remark字段为aa的记录,由于remark字段没有索引,所以全表扫描(type:ALL),一共有2条记录,扫描了2行(rows:2),1条符合条件(filtered:50,1/2);

tc_id无索引 再查询t即teacher表使用tc_id和之前的tc.id关联;由于是关联查询,不是索引,全表扫描,所以type为ALL。

tc_id有索引再查询t即teacher表使用tc_id和之前的tc.id关联;由于是关联查询,索引扫描,能返回0或1或多条记录,所以type为ref。

(5)range: 表示使用索引范围查询, 通过索引字段范围获取表中部分数据记录. 这个类型通常出现在 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, IN() 操作中。

 desc select * from teacher where id>2;
 desc select * from teacher where id in (1,2,3);

(6)index: 扫描索引树

如果索引是复合索引,并且复合索引列满足select所需的所有数据,则仅扫描索引树。在这种情况下,Extra为Using index。仅索引扫描通常比ALL索引的大小通常小于表数据更快。

索引列不满足select所需的所有数据,此时需要回表扫描;按索引顺序查找数据行。Uses index没有出现在Extra列中。

 -- 查看teacher表索引
 show index from teacher;
 -- 查询tc_id,执行计划
 desc select tc_id from teacher;
 -- 按tc_id索引分组,执行计划
 desc select name from teacher group by tc_id;

查询tc_id,扫描索引树,type为index,Extra为Using index;

按tc_id分组,全表扫描,以按索引顺序查找数据行。

(7)ALL: 全表扫描,没有任何索引可以使用时。这是最差的情况,应该避免。

 -- 查看teacher表索引
 show index from teacher;
 desc select * from teacher where name='a';

由于name字段不存在索引,type:ALL全表扫描;可通过对name字段设置索引进行优化。

六、possible_keys:指示MySQL可以从中选择查找此表中的行的索引。

七、key:MySQL查询实际使用到的索引。

-- 创建course表
create table course(id int primary key,name varchar(20),t_id int,key index_name(name),key index_tid(t_id));
-- 插入数据
insert into course values (1,'Java',1), (2,'Python',2);
-- 查询1
desc select * from course where name='Java' or t_id=1;
-- 查询2
desc select * from course where name='Java';

查看执行计划

查询1,查询name为Java或t_id为1的记录;可能用到的索引possible_keys为index_name,index_tid;实际用到的索引key为NULL

查询2,查询name为Java;可能用到的索引possible_keys为index_name;实际用到的索引key为index_name

八、key_len:表示索引中使用的字节数(只计算利用索引作为index key的索引长度,不包括用于group by/order by的索引长度)

  • 一般地,key_len 等于索引列类型字节长度,例如int类型为4 bytes,bigint为8 bytes;
  • 如果是字符串类型,还需要同时考虑字符集因素,例如utf8字符集1个字符占3个字节,gbk字符集1个字符占2个字节
  • 若该列类型定义时允许NULL,其key_len还需要再加 1 bytes
  • 若该列类型为变长类型,例如 VARCHAR(TEXT\BLOB不允许整列创建索引,如果创建部分索引也被视为动态列类型),其key_len还需要再加 2 bytes

字符集会影响索引长度、数据的存储空间,为列选择合适的字符集;变长字段需要额外的2个字节,固定长度字段不需要额外的字节。而null都需要1个字节的额外空间,所以以前有个说法:索引字段最好不要为NULL,因为NULL让统计更加复杂,并且需要额外一个字节的存储空间。

-- key_len的长度计算公式:

-- varchar(len)变长字段且允许NULL      : len*(Character Set:utf8=3,gbk=2,latin1=1)+1(NULL)+2(变长字段)
-- varchar(len)变长字段且不允许NULL    : len*(Character Set:utf8=3,gbk=2,latin1=1)+2(变长字段)

-- char(len)固定字段且允许NULL         : len*(Character Set:utf8=3,gbk=2,latin1=1)+1(NULL)
-- char(len)固定字段且不允许NULL       : len*(Character Set:utf8=3,gbk=2,latin1=1)

下面验证一下结论:

-- 创建user_info表
create table user_info( id int comment '主键',
    name varchar(10) character set utf8 not null comment '姓名',
    alias_name varchar(10) character set utf8 comment '姓名',
    role_id int comment '角色id',
    remark varchar(10) character set gbk not null comment '备注',
    primary key(id),
    key index_name(name),
    key index_alias(alias_name),
    key index_role(role_id),
    key index_remark(remark)
)engine=innodb;
-- 插入数据
insert into user_info values (1,'a','aa',1,'aaa');
-- 按主键查询
desc select * from user_info where id=1;
-- 按索引role_id查询
desc select * from user_info where role_id=1;

按照主键id查询possible_keys为primary,实际用到的索引key为primary,key_len为4;

按照索引role_id查询possible_keys为index_role,实际用到的索引key为index_role,key_len为5;

分析结果:按照role_id比按照id(均为int类型)的key_len大5-4=1,因为role_id可以为null,需要一个标志位;

 -- 按照name查询 varchar(10) not null utf8 一个字符占3个字节 10*3+2(变长)=32
 desc select * from user_info where name='a';
 -- 按照alias_name查询 varchar(10) utf8 一个字符占3个字节 10*3+2(变长)+1(null标志位)=33
 desc select * from user_info where alias_name='aa';

按照name查询possible_keys为index_name,实际用到的索引key为index_name,key_len为32=10*3+2(变长);

按照alias_name查询possible_keys为index_alias,实际用到的索引key为index_alias,key_len为33=10*3+2(变长)+1(null标志位);

分析结果:name与remark均为变长且字符集一致,remark可以为null,33-32=1多占一个标志位;

 -- 按照name查询 varchar(10) not null utf8 一个字符占3个字节 10*3+2(变长)=32
 desc select * from user_info where name='a';
 -- 按照remark查询 varchar(10) not null gbk 一个字符占2个字节 10*2+2(变长)=22
 desc select * from user_info where remark='aaa';

按照name查询possible_keys为index_name,实际用到的索引key为index_name,key_len为32=10*3(utf8一个字符3个字节)+2(变长);

按照remark查询possible_keys为index_remark,实际用到的索引key为index_remark,key_len为22=10*2(gbk一个字符2个字节)+2(变长);

分析结果:name与remark均为变长但字符集不一致,分别为utf8与gbk;符合公式;

 -- 将name修改为char(10) 定长 character set utf8 not null
 alter table user_info modify name char(10)  character set utf8 not null;
 -- 按照name查询 varchar(10) not null utf8 一个字符占3个字节 10*3=30
 desc select * from user_info where name='a';

按照name查询possible_keys为index_name,实际用到的索引key为index_name,key_len为30;

因为将name修改为char(10) 定长 character set utf8 not null,10*3=30;符合公式

九、ref:显示该表的索引字段关联了哪张表的哪个字段

desc select * from user,role where user.role_id=role.id;

通过执行计划可知,role表执行计划ref为study.user.role_id;说明role.id关联user.role_id;

十、rows:根据表统计信息及选用情况,大致估算出找到所需的记录或所需读取的行数,数值越小越好

十一、filtered:返回结果的行数占读取行数的百分比,值越大越好

-- 查看teacher数据
select * from teacher;
-- 查看teacher_card数据
select * from teacher_card;
-- 查询语句
select * from teacher t  join  teacher_card tc on t.tc_id=tc.id  where t.name='a';
-- 执行计划
desc select * from teacher t  join  teacher_card tc on t.tc_id=tc.id  where t.name='a';

根据上面的知识;可知id相同,由上至下依次执行,分析结果可知:

先查询t表就是teacher表中name字段为a的记录,由于name字段没有索引,所以全表扫描(type:ALL),一共有3条记录,扫描了3行(rows:3),1条符合条件(filtered:33.33 1/3);

再查询tc即teacher_card表使用主键和之前的t.tc_id关联;扫描索引(type:ref),返回1条记录,最终返回1条记录,(filtered:100 1/1)。

十二、extra:包含不适合在其他列中显示但十分重要的额外信息。常见的值如下

use filesort:MySQL会对数据使用非索引列进行排序,而不是按照索引顺序进行读取;若出现改值,应优化索引

-- 查看user索引
show index from user;
-- 查询name并排序
desc select name from user order by name;
-- 为name列设置索引,优化
alter table user add index index_name(name);
-- 查询name并排序
desc select name from user order by name;

use temporary:使用临时表保存中间结果,比如,MySQL在对查询结果排序时使用临时表,常见于order by和group by;若出现改值,应优化索引

use index:表示select操作使用了索引覆盖,避免回表访问数据行,效率不错

use where:where子句用于限制哪一行

-- 创建student表
create  table student(
    id int,
    first_name varchar(10),
    last_name varchar(10),
    primary key(id),
    key index_first(first_name)
)engine=innodb default charset=utf8;
-- 插入数据
insert into student values (1,'a','b');
-- 按照first_name查找
desc select first_name,last_name from student where first_name='a';
-- 设置first_name,last_name复合索引
alter table student drop index index_first;
alter table student add index index_name(first_name,last_name);
-- 按照first_name查找
desc select first_name,last_name from student where first_name='a';

分析结果:

当设置first_name为普通索引(单列索引),按照first_name查询;type:ref、possible_keys:indes_first、key:indes_first、extra:null,用到索引;

当设置first_name,last_name为复合索引(联合索引),按照first_name查询;type:ref、possible_keys:indes_name、key:indes_name、extra:Using index;type:ref用到索引,因为是复合索引不需要回表扫描,extra:Using index索引覆盖;注意此时key_len为33=10*3(utf8)+2(变长)+1(null标志位),用到了复合索引的一部分即first_name

当设置first_name,last_name为复合索引(联合索引),按照last_name查询;type:index、possible_keys:null、key:indes_name、extra:Using where,Using index;type:index而不是ref,扫描索引树,复合索引的最左原则;此时key_len为66=10*3(utf8)+2(变长)+1(null)+10*3(utf8)+2(变长)+1(null标志位);Using where应where子句进行限制

小结:

根据MySQL执行计划的输出,分析索引使用情况、扫描的行数可以预估查询效率;进而可以重构SQL语句、调整索引,提升查询效率。

本文只是简单介绍一下MySQL执行计划,想全面深入了解MySQL,可优先阅读MySQL官方手册

总结

到此这篇关于MySQL执行计划的文章就介绍到这了,更多相关MySQL执行计划内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • mysql执行计划介绍

    烂sql不仅直接影响sql的响应时间,更影响db的性能,导致其它正常的sql响应时间变长.如何写好sql,学会看执行计划至关重要.下面我简单讲讲mysql的执行计划,只列出了一些常见的情况,希望对大家有所帮助. 测试表结构: 复制代码 代码如下: CREATE TABLE `t1` (  `c1` int(11) NOT NULL DEFAULT '0',  `c2` varchar(128) DEFAULT NULL,  `c3` varchar(64) DEFAULT NULL,  `c4`

  • MySQL中执行计划explain命令示例详解

    前言 explain命令是查看查询优化器如何决定执行查询的主要方法. 这个功能有局限性,并不总会说出真相,但它的输出是可以获取的最好信息,值得花时间去了解,因为可以学习到查询是如何执行的. 调用EXPLAIN 在select之前添加explain,mysql会在查询上设置一个标记,当执行查询计划时,这个标记会使其返回关于执行计划中每一步的信息,而不是执行它. 它会返回一行或多行信息,显示出执行计划中的每一部分和执行次序. 这是一个简单的explain效果: 在查询中每个表在输出只有一行,如果查询

  • 详解 MySQL 执行计划

    EXPLAIN语句提供有关MySQL如何执行语句的信息.EXPLAIN与SELECT,DELETE,INSERT,REPLACE和UPDATE语句一起使用. EXPLAIN为SELECT语句中使用的每个表返回一行信息.它按照MySQL在处理语句时读取它们的顺序列出了输出中的表. MySQL使用嵌套循环连接方法解析所有连接.这意味着MySQL从第一个表中读取一行,然后在第二个表,第三个表中找到匹配的行,依此类推.处理完所有表后,MySQL输出所选列,并通过表列表回溯,直到找到一个表,其中有更多匹配

  • mysql执行计划id为空(UNION关键字)详解

    简介 在工作过程中,有时候会对慢查询进行调优.对于MySQL的SQL语句调优,MySQL本身提供了强大的explain关键字用于查询分析执行计划.本文主要给大家介绍了关于mysql执行计划id为空(UNION关键字)的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的 介绍吧 UNION 操作符用于合并两个或多个 SELECT 语句的结果集.例如,我有两个表,表1记录的是公司男员工的数据,包括年龄.姓名.职位.表2记录的是公司女员工的数据,包括姓名.家庭住址.手机号等字段.这时,

  • MySQL中通过EXPLAIN如何分析SQL的执行计划详解

    前言 在MySQL中,我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息,包括在SELECT语句执行过程中表如何连接和连接的顺序. 下面分别对EXPLAIN命令结果的每一列进行说明: .select_type:表示SELECT的类型,常见的取值有: 类型 说明 SIMPLE 简单表,不使用表连接或子查询 PRIMARY 主查询,即外层的查询 UNION UNION中的第二个或者后面的查询语句 SUBQUERY 子查询中的第一个 .table:输出结果集的表(表别名) .t

  • MySQL执行计划的深入分析

    前言 在之前的面试过程中,问到执行计划,有很多童鞋不知道是什么?甚至将执行计划与执行时间认为是同一个概念.今天我们就一起来了解一下执行计划到底是什么?有什么用途? 执行计划是什么? 执行计划,简单的来说,是SQL在数据库中执行时的表现情况,通常用于SQL性能分析,优化等场景. 一. 执行计划能告诉我们什么? SQL如何使用索引 联接查询的执行顺序 查询扫描的数据函数 二. 执行计划中的内容 SQL执行计划的输出可能为多行,每一行代表对一个数据库对象的操作 1. ID列 ID列中的如果数据为一组数

  • MySql中如何使用 explain 查询 SQL 的执行计划

    explain命令是查看查询优化器如何决定执行查询的主要方法. 这个功能有局限性,并不总会说出真相,但它的输出是可以获取的最好信息,值得花时间去了解,因为可以学习到查询是如何执行的. 1.什么是MySQL执行计划 要对执行计划有个比较好的理解,需要先对MySQL的基础结构及查询基本原理有简单的了解. MySQL本身的功能架构分为三个部分,分别是 应用层.逻辑层.物理层,不只是MySQL ,其他大多数数据库产品都是按这种架构来进行划分的. 应用层,主要负责与客户端进行交互,建立链接,记住链接状态,

  • 带你学习MySQL执行计划

    1.执行计划简介 执行计划是指一条 SQL 语句在经过 MySQL 查询优化器的优化会后,具体的执行方式.MySQL 为我们提供了  EXPLAIN 语句,来获取执行计划的相关信息.需要注意的是,EXPLAIN 语句并不会真的去执行相关的语句,而是通过查询优化器对语句进行分析,找出最优的查询方案,并显示对应的信息. 执行计划通常用于 SQL 性能分析.优化等场景.通过 explain 的结果,可以了解到如数据表的查询顺序.数据查询操作的操作类型.哪些索引可以被命中.哪些索引实际会命中.每个数据表

  • Mysql深入探索之Explain执行计划详析

    前言 如何写出效率高的SQL语句,提到这必然离不开Explain执行计划的分析,至于什么是执行计划,如何写出高效率的SQL,本篇文章将会一一介绍. 执行计划 执行计划是数据库根据 SQL 语句和相关表的统计信息作出的一个查询方案,这个方案是由查询优化器自动分析产生的. 使用explain关键字可以模拟优化器执行 SQL 查询语句,从而知道 MySQL 是如何处理你的 SQL 语句的,分析你的 select 语句或是表结构的性能瓶颈,让我们知道 select 效率低下的原因,从而改进我们的查询.

  • MYSQL explain 执行计划

    使用方法,在select语句前加上explain就可以了: 如:explain select * from test1 EXPLAIN列的解释: table:显示这一行的数据是关于哪张表的 type:这是重要的列,显示连接使用了何种类型.从最好到最差的连接类型为const.eq_reg.ref.range.indexhe和ALL possible_keys:显示可能应用在这张表中的索引.如果为空,没有可能的索引.可以为相关的域从WHERE语句中选择一个合适的语句 key: 实际使用的索引.如果为

随机推荐