explain说明
EXPLAIN是MySQl必不可少的一个分析工具,主要用来测试sql语句的性能及对sql语句的优化,或者说模拟优化器执行SQL语句。 在select语句之前增加explain关键字,执行后MySQL就会返回执行计划的信息
而不是执行sql。但如果from中包含子查询,MySQL仍会执行该子查询,并把子查询的结果放入临时表中。
它显示了mysql如何使用索引来处理select语句以及连接表,可以帮助选择更好的索引和写出更优化的查询语句
创建几个个简单的表做关联用来演示
user表
DROP TABLE IF EXISTS `upms_user`;
CREATE TABLE `upms_user` (
`user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
`username` varchar(64) DEFAULT NULL COMMENT '用户名',
`password` varchar(255) DEFAULT NULL COMMENT '密码',
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=40 DEFAULT CHARSET=utf8mb4;
role表
DROP TABLE IF EXISTS `upms_role`;
CREATE TABLE `upms_role` (
`role_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
`role_name` varchar(64) DEFAULT NULL COMMENT '角色名称',
`role_code` varchar(64) DEFAULT NULL COMMENT '角色编码',
`role_desc` varchar(255) DEFAULT NULL COMMENT '角色描述',
`tenant_id` int(5) DEFAULT '1' COMMENT '租户id',
PRIMARY KEY (`role_id`)
) ENGINE=InnoDB AUTO_INCREMENT=42 DEFAULT CHARSET=utf8mb4;
user_role表
DROP TABLE IF EXISTS `upms_user_role`;
CREATE TABLE `upms_user_role` (
`user_id` int(11) NOT NULL COMMENT '用户ID',
`role_id` int(11) NOT NULL COMMENT '角色ID',
PRIMARY KEY (`user_id`,`role_id`),
KEY `user_id` (`user_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
执行一个简单关联查询查看explain 查看都有哪些列
EXPLAIN SELECT
*
FROM
upms_user USER
INNER JOIN upms_user_role urole ON USER .user_id = urole.user_id
INNER JOIN upms_role role ON role.role_id = urole.role_id
执行结果
可以看见一共以下列:
id: 选择标识符 select_type: 查询类型
table: 输出结果集的表
partitions: 匹配的分区
type: 表的连接类型
possible_keys: 查询时可能使用的索引
key: 实际使用的索引
key_len: 索引字段的长度
ref: 列与索引的比较
rows: 扫描出的行数 filtered: 按表条件过滤的行百分比
extra: 执行情况描述和说明
结合sql对每列进行详细说明
id列
id列的编号是select的序列号,有几个select就有几个id,并且id的顺序是按select出现的顺序增长的。
id越大执行优先级越高,id相同则从上往下执行,id为NULL最后执行
id相同的情况下
一般都是直接关联查询,id相同从上往下执行
id不同的情况下
一般就是带有from 查询或者子查询等明确循序的sql,id越大,执行优先级越高
select type列,select type表示对应行是简单还是复杂的查询。
simple:简单查询。查询不包含子查询和union。
还是拿刚才的sql例子,执行后发现都是simple,因为没有子查询和union如下
primary:复杂查询中最外层的select
subquery:包含在select中的子查询
不在from子句中,实际测试在from中的也会被标记subquery
derived:包含在from子句中的子查询(实际)。MySQL会将结果存放在一个临时表中,也称为派生表。
实际测试在from中的也会被标记subquery*
union:在union关键字随后的selelct。
会先执行uinon 后面的select 语句然后结果再执行union 前面的select 结果最后汇总
table列
这一列表示explain的一行正在访问哪个表。
当from子句中有子查询时,table列是格式,表示当前查询依赖id=N的查询,于是先执行id=N的查询。
当有union时,UNION RESULT的table列的值为<union 1,2>,1和2表示参与union的select行id。
type列(重点,关系到是否用了索引以及索引类型,用来优化查询)
这一列表示关联类型或访问类型,即MySQL决定如何查找表中的行,查找数据行对应的大概范围。 依次从最优到最差的分别为:system>const>eq_ref>ref>range>index>All
一般来说,得保证查询达到range级别,最好达到ref。
NULL:MySQL能够在优化阶段分解查询语句,在执行阶段用不着在访问表或索引。例如:在索引列中选取最小值,可以单独查找索引来完成,不需在执行时访问表
type 类型列举排序说明
主要有如下类型:
system
const
eq_ref
ref
range
index
All
这一列表示关联类型或访问类型,即MySQL决定如何查找表中的行,查找数据行对应的大概范围。
依次从最优到最差的分别为:system>const>eq_ref>ref>range>index>All
一般来说,得保证查询达到range级别,最好达到ref。
const、system (其实可以认为是一个,system表示表里只有一行数据的时候的const)
用于primay key或unique key的所有列与常数比较时,所以表最多有一个匹配行,读取1次,速读较快。system 是const的特例,表中只有一行元素匹配时为system
这里直接用了主键去查所以是const,如果表里只有一条数据,那么就是system,unique key效果是一样的
eq_ref(一般都是带有关联查询且最多返回一条,情况很少,暂时忽略)
primay key或 unique key索引的所有部分被连接使用,最多只会返回一条符合条件的记录。这可能是const之外最好的联接类型,简单的select查询不会出现这种type
ref(常规长训场景最好达到此索引级别)
相比eq_ref,不适用唯一索引,而是使用普通索引或者唯一索引的部分前缀,索引要和某个值相比较,可能会找到多个符合条件的行。 简单select查询,name是普通索引(非主键索引或唯一索引)
这种关联查询比较常见,基本上是关联用到了普通索引
range(比较常见,比如集合内,日期区间查询等)
范围扫描通常出现在in(), between,>,<,>=等操作中。使用一个索引来检索给定范围的行。
index(基本上是无条件查询,但是查询内容是索引)
index:扫描全表索引,通常比All快一些
all:(全表扫描,一般很可能意味着需要优化了)
上面的查询索引字段变为 即没用到索引,则走了全表扫描*
possible_keys列(不是一定准确的)
这一列显示select可能会使用哪些查询来查找。
key列(实际准确用到的)
这一列显示MySQL实际采用哪个索引对该表的访问。
如果没有使用索引,则改列为NULL
key_len列
这一列显示了mysql在索引里使用的字节数,通过这个值可以估算出具体使用了索引中的哪些列。
ref列
这一列显示了在key列记录的索引中,表查找值所用到的列或常量,常见的有: const(常量),字段名等
row列(读取并检测的行数,注意这个不是结果集的行数)
Extra列(额外信息)
包含内容如下:
Using index:使用覆盖索引(结果集的字段是索引,即select后的film_id)
Using index condition:查询的列不完全被索引覆盖,where条件中是一个前导的范围
Using where:使用where语句来处理结果,查询的列未被索引覆盖
Using where:使用where语句来处理结果,查询的列未被索引覆盖
Using temporary:mysql需要创建一张临时表来处理查询。出现这种情况一般要进行优化,首先要想到是索引优化。
常用优化方法
1、选取最适用的字段属性
2、使用连接(JOIN)来代替子查询(Sub-Queries)
3、使用联合(UNION)来代替手动创建的临时表
索引何时应该使用
需创建索引的情况:
1.主键,自动建立唯一索引
2.频繁作为查询的条件的字段
3.查询中与其他表关联的字段存在外键关系
4.查询中排序的字段,排序字段若通过索引去访问将大大提高排序的速度
5.查询中统计或者分组字段 避免创建索引的情况:
1.数据唯一性差的字段不要使用索引 比如性别,只有两种可能数据。意味着索引的二叉树级别少,多是平级。这样的二叉树查找无异于全表扫描。
2.频繁更新的字段不要使用索引 比如登录次数,频繁变化导致索引也频繁变化,增大数据库工作量,降低效率。
3.字段不在where语句出现时不要添加索引 只有在where语句出现,mysql才会去使用索引
4.数据量少的表不要使用索引 使用了改善也不大 三、哪些sql能命中索引
1.前导模糊查询不能使用索引,如name like ‘%nowjava’ 2、Union、in、or可以命中索引,建议使用in。 3、负条件查询不能使用索引,可以优化为in查询,其中负条件有!=、<>、not in、not exists、not like等
4、联合索引最左前缀原则,又叫最左侧查询,如果在(a,b,c)三个字段上建立联合索引,那么它能够加快a|(a,b)|(a,b,c)三组的查询速度。
5、建立联合查询时,区分度最高的字段在最左边
6、如果建立了(a,b)联合索引,就不必再单独建立a索引。同理,如果建立了(a,b,c)索引就不必再建立a,(a,b)索引
7、存在非等号和等号混合判断条件时,在建索引时,要把等号条件的列前置 8、范围列可以用到索引,但是范围列后面的列无法用到索引。
索引最多用于一个范围列,如果查询条件中有两个范围列则无法全用到索引。范围条件有:<、<=、>、>=、between等。
9、把计算放到业务层而不是数据库层。在字段上计算不能命中索引, 10、强制类型转换会全表扫描,
如果phone字段是varcher类型,则下面的SQL不能命中索引。Select * from user where
phone=1380000000 11、更新十分频繁、数据区分度不高的字段上不宜建立索引。
更新会变更B+树,更新频繁的字段建立索引会大大降低数据库性能。
“性别”这种区分度不太大的属性,建立索引是没有什么意义的,不能有效过滤数据,性能与全表扫描类似。
一般区分度在80%以上就可以建立索引。区分度可以使用count(distinct(列名))/count()来计算。
12、利用覆盖索引来进行查询操作,避免回表。
被查询的列,数据能从索引中取得,而不是通过定位符row-locator再到row上获取,即“被查询列要被所建的索引覆盖”,这能够加速度查询。
13、建立索引的列不能为null,使用not null约束及默认值 14、利用延迟关联或者子查询优化超多分页场景,
MySQL并不是跳过offset行,而是取offset+N行,然后放弃前offset行,返回N行,那当offset特别大的时候,效率非常低下,要么控制返回的总数,要么对超过特定阈值的页进行SQL改写。
15、业务上唯一特性的字段,即使是多个字段的组合,也必须建成唯一索引。
16、超过三个表最好不要用join,需要join的字段,数据类型必须一致,多表关联查询时,保证被关联的字段需要有索引。
17、如果明确知道查询结果只要一条,limit 1能够提高效率,比如验证登录的时候。 18、Select语句务必指明字段名称
19、如果排序字段没有用到索引,就尽量少排序 20、尽量用union all 代替
union。Union需要将集合合并后在进行唯一性过滤操作,这会涉及到排序,大量的cpu运算,加大资源消耗及延迟,当然,使用union
all的前提条件是两个结果集没有重复数据。*