mysql explain中的type列含义和extra列的含义

很多朋友在用mysql进行调优的时候都肯定会用到explain来看select语句的执行情况,这里简单介绍结果中两个列的含义。

1 type列

官方的说法,说这列表示的是“访问类型”,更通俗一点就是:mysql找到需要的数据行的方式。一下就是从效率最差到最好顺序分别介绍下:

All 这个就是所谓的全表扫描,没有用到任何的index,mysql就是从头到尾把整个表遍历一边,找到所需要的数据行。效率是最差的。如下图,这个表中的usertype不是索引,这个查询中没有用到任何索引,所以就出现了全表扫描的结果。

index type列中出现了index,含义仅仅是局限在扫描全表的顺序是按照索引顺序扫描的,仅仅是按索引顺序去扫描的。它的有点是避免了排序,因为索引就是已经排序好的,缺点就是要承担按照索引次序读取整张表的开销。如下,这个查询中order by id,id是这个表的索引,但是因为没有在where中出现任何的索引列,所以它也只是索引顺去扫描了全表。(这里强调一下,你的查询语句中where条件中没有索引,只是order by 的时候用了index,而且没有用limit限制,type这里显示的是all,也就是这种情况下没有limit,还是扫面全表的)

range 这个一般就是在你的where语句中出现了between或者“>”这种符号的时候会出现这个。这种范围扫描索引扫描比全表扫描要好,因为它只需要开始于索引的某一点,而结束语另一点,不用扫描全部索引。

ref 这也是一种索引访问,它返回所有匹配某个单独值的行,然而,它可能会找到多个符合条件的行,所以他应该属于查找和扫描的混合体。

const,system 当mysql能对查询的部分就行优化,并且转换成一个常量的时候,它就会使用这种访问类型了。比如你把一行的主键当做where条件放进去,那mysql就可以把它转换成一个常量,然后查询。如下图:uid是主键,作为where条件就能出现这个效率最高的查询结果。

NULL是最好的,不用访问索引或表,直接获得数据。

2 extra列

extra列中出现的信息一般不是太重要,但是还是有很多信息我们可以从这里面获取到:

using index:出现这个说明mysql使用了覆盖索引,避免访问了表的数据行,效率不错!

using where:这说明服务器在存储引擎收到行后将进行过滤。有些where中的条件会有属于索引的列,当它读取使用索引的时候,就会被过滤,所以会出现有些where语句并没有在extra列中出现using where这么一个说明。

using temporary:这意味着mysql对查询结果进行排序的时候使用了一张临时表。

using filesort:这个说明mysql会对数据使用一个外部的索引排序,而不是按照表内的索引顺序进行读取。

时间: 2024-08-29 00:35:58

mysql explain中的type列含义和extra列的含义的相关文章

mysql explain中的 “Select tables optimized away”

mysql explain中的 “Select tables optimized away” http://blog.chinaunix.net/uid-10449864-id-2956845.html2009年 今天在做SQL语句优化的时候,在explain的时候,有这样一个提示: mysql> explain SELECT max( up_start ) AS up_start FROM test WHERE up_start > '2008-01-19 00:00:00' and up_

mysql explain 中type的归纳

为了更好的理解连接类型(type),将根据查询条件的不同对连接类型进行简单归纳. 表定义如下: 1.id为主键 mysql> show create table key_id; +--------+-------------------------------------------------------------------------------------------------------------------------------------------------------

为什么rows这么大,在mysql explain中---写在去acumg听讲座的前一夜

这周五下班前,发现了一个奇怪问题,大概是这个背景 一张表,结构为 Create Table: CREATE TABLE `out_table` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(20) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=Innodb AUTO_INCREMENT=36865 DEFAULT CHARSET=latin1 总共有37K rows的数据,数据大概是这样 +----+-

ICMPv6协议中各种Type的详细取值范围及其含义

https://www.ipv6s.com/basis/20100912134.html 在ICMPv6中的Type字段定义中,0-127为错误消息(Error messages),而128-255为信息消息(Informational messages),其中每种Type定义一种类型及其含义分类,而部分Type中由根据Code值指定该类别下更详细的错误或信息分类. 针对ICMPv6协议属于IPv6协议的一部分,因此该部分对IPv6的ND邻居发现协议进行了很详细的分类,ND邻居发现协议由ICMP

mysql explain 中key_len的计算

今天丁原问我mysql执行计划中的key_len是怎么计算得到的,当时还没有注意,在高性能的那本书讲到过这个值的计算,但是自己看执行计划的时候一直都没有太在意这个值,更不用说深讨这个值的计算了: ken_len表示索引使用的字节数,根据这个值,就可以判断索引使用情况,特别是在组合索引的时候,判断所有的索引字段都被查询用到. 在查看官方文档的时候,也没有发现详细的key_len的计算介绍,后来做了一些测试,在咨询了丁奇关于变长数据类型的值计算的时候,突然想到innodb 行的格式,在这里的计算中有

MYSQL EXPLAIN 中的KEY_LEN的说明

对于explain extended 查看执行计划里面的一些信息作为一个DBA还是必须掌握的. 参考博文:http://www.cnblogs.com/xuanzhi201111/p/4554769.html 环境: MySQL5.6.36 默认字符集: utf8 一.前置回顾: 1.数值型的字段长度 字段类型   长度    UNSIGNED          SIGNED有符号型           适用场合 tinyint:    1bytes   2^8-1 0-255        

mysql explain中key_len的计算

ken_len表示索引使用的字节数,根据这个值,就可以判断索引使用情况,特别是在组合索引的时候,判断是否所有的索引字段都被查询用到. key_len显示了条件检索子句需要的索引长度,但 ORDER BY.GROUP BY 子句用到的索引则不计入 key_len 统计值: 关于 key_len 的计算规则: • 当索引字段为定长数据类型,比如:char,int,datetime,需要有是否为空的标记,这个标记需要占用1个字节:• 当索引字段为变长数据类型,比如:varchar,除了是否为空的标记外

MYSQL EXPLAIN执行计划命令详解(支持更新中)

本文来自我的github pages博客http://galengao.github.io/ 即www.gaohuirong.cn 摘要: 本篇是根据官网中的每个一点来翻译.举例.验证的:英语不好,所以有些话语未必准确,请自行查看官网,若有些点下面没有例子的是因为当时一下子没有想出那么多来,如果大家有遇上好的例子,欢迎在下面留言我持续更新 查看执行计划的关键EXPLAIN 版本MYSQL5.6,用到的库是官网例子sakila,自行下载导入 由于要把每个点都翻译出来,还需要举例,所以需要一定的时间

MySQL explain语法

explain语法 有两种用法: 1.EXPLAIN tbl_name 2.EXPLAIN [EXTENDED] SELECT select_options 为了更好的说明它,我们需要建两张表,下面的语句用于创建一张测试用的订单表: CREATE TABLE `t_order` ( `order_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '订单ID', `express_type` tinyint(1) unsigned NOT N