数据库
首页 > 数据库> > 再次研究 MySQL EXPLAIN type列的解释和测试

再次研究 MySQL EXPLAIN type列的解释和测试

作者:互联网

 type列 其实很关键。 解释如下: 

type列

这一列表示关联类型或访问类型,即MySQL决定如何查找表中的行。

依次从最优到最差分别为:system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

NULL:mysql能够在优化阶段分解查询语句,在执行阶段用不着再访问表或索引。例如:在索引列中选取最小值,可以单独查找索引来完成,不需要在执行时访问表

 

const, system:mysql能对查询的某部分进行优化并将其转化成一个常量(可以看show warnings 的结果)。用于 primary key 或 unique key 的所有列与常数比较时,所以表最多有一个匹配行,读取1次,速度比较快。

 

eq_ref:primary key 或 unique key 索引的所有部分被连接使用 ,最多只会返回一条符合条件的记录。这可能是在 const 之外最好的联接类型了,简单的 select 查询不会出现这种 type。

 

ref:相比 eq_ref,不使用唯一索引,而是使用普通索引或者唯一性索引的部分前缀,索引要和某个值相比较,可能会找到多个符合条件的行。

 

ref_or_null:类似ref,但是可以搜索值为NULL的行。

 

index_merge:表示使用了索引合并的优化方法。 例如下表:id是主键,tenant_id是普通索引。or 的时候没有用 primary key,而是使用了 primary key(id) 和 tenant_id 索引

 

range:范围扫描通常出现在 in(), between ,> ,<, >= 等操作中。使用一个索引来检索给定范围的行。

 

index:和ALL一样,不同就是mysql只需扫描索引树,这通常比ALL快一些。

    测试一下:   注意: actor 有主键id, 无其他索引, actor_no_key 无主键,有一个唯一索引:addresss , 无其他索引,   
CREATE TABLE `actor` (
  `id` int(11) NOT NULL,
  `name` varchar(45) DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `actor_no_key` (
  `id` int(11) NOT NULL,
  `name` varchar(45) DEFAULT NULL,
  `addresss` varchar(45) DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  UNIQUE KEY `index_addresss` (`addresss`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

然后 分别随意插入3行数据。

 

EXPLAIN SELECT COUNT(1) FROM actor;

EXPLAIN SELECT COUNT(*) FROM actor;
EXPLAIN SELECT COUNT(*) FROM actor WHERE id > 1;
EXPLAIN SELECT COUNT(name) FROM actor;
EXPLAIN SELECT COUNT(name) FROM actor_no_key;
EXPLAIN SELECT COUNT(1) FROM actor_no_key;
EXPLAIN SELECT COUNT(id) FROM actor_no_key;
EXPLAIN SELECT COUNT(*) FROM actor_no_key;
EXPLAIN SELECT COUNT(name) FROM actor_no_key WHERE id > 0;
EXPLAIN SELECT COUNT(addresss) FROM actor_no_key WHERE id > 1;
EXPLAIN SELECT COUNT(1) FROM actor_no_key;

 

结果是:

EXPLAIN SELECT COUNT(1) FROM actor; 走 PRIMARY 索引: Using index

—— 为什么 possible_keys 为空? 
EXPLAIN SELECT COUNT(*) FROM actor; 同上


EXPLAIN SELECT COUNT(*) FROM actor WHERE id > 1;  基本同上,Extra 是 Using where; Using index

 

 

 

 


EXPLAIN SELECT COUNT(name) FROM actor;   因为 name上面没有索引, 所以是走 全表扫描。

 

 

 

 


EXPLAIN SELECT COUNT(name) FROM actor_no_key;  同上,因为 name上面没有索引, 所以是走 全表扫描。

 

 

 


EXPLAIN SELECT COUNT(1) FROM actor_no_key;  因为addresss字段存在唯一索引 index_addresss, 所以是 Using index, 不过 key_len 是 138 ,  有点长..

 

 

 


EXPLAIN SELECT COUNT(id) FROM actor_no_key;   因为 id 上面没有索引, 所以是走 全表扫描。

 

 

 


EXPLAIN SELECT COUNT(*) FROM actor_no_key;  同EXPLAIN SELECT COUNT(1) FROM actor_no_key; 

 

 

 


EXPLAIN SELECT COUNT(name) FROM actor_no_key WHERE id > 0;  因为 id 上面没有索引, 所以是走回表过滤(where 条件就相当于是过滤条件),(过滤 和扫描是什么区别? 可以认为过滤前需要扫描一下)。

 

 

 注意 filtered 是 33.33 , 为什么其他的都是 100 ?  可能是因为数据只有三行的原因, 然后因为 1/3 = 33.33 % ? 但是新增了几行,发行  还是33.33 ..


EXPLAIN SELECT COUNT(addresss) FROM actor_no_key WHERE id > 1;   同上


EXPLAIN SELECT COUNT(1) FROM actor_no_key;  同EXPLAIN SELECT COUNT(1) FROM actor_no_key;   

 

 

 

 

 license_record2 表有 12503260 行数据, -- 

实际是12696243 

 

 

 

CREATE TABLE `license_record2` (
`id` bigint(20) NOT NULL COMMENT '主键',
`created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`created_by` varchar(20) COLLATE utf8_unicode_ci NOT NULL COMMENT '创建人',
`updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新时间',
`updated_by` varchar(20) COLLATE utf8_unicode_ci NOT NULL COMMENT '更新人',
`app_id` varchar(20) COLLATE utf8_unicode_ci NOT NULL COMMENT 'APP_ID',
`device_id` varchar(255) COLLATE utf8_unicode_ci NOT NULL COMMENT 'DEVICE_ID',
`model_id` varchar(50) COLLATE utf8_unicode_ci NOT NULL COMMENT 'model_id',
`manufacturer_id` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '制造商ID',
`user_id` varchar(60) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'user_id',
`brand_name` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '包名-',
`status` varchar(64) COLLATE utf8_unicode_ci NOT NULL COMMENT '状态',
`expire_date` datetime DEFAULT NULL COMMENT '到期时间',
`deleted` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除',
`status_code` tinyint(4) NOT NULL DEFAULT '1' COMMENT '授权状态,0、失败1、成功2、撤回',
`ip_address` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'ip地址',
`sign` varchar(2) COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE,
KEY `app_id` (`app_id`,`device_id`,`manufacturer_id`,`model_id`,`brand_name`,`status_code`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ROW_FORMAT=DYNAMIC;

 

注意索引:  `app_id`, `device_id`, `manufacturer_id`, `model_id`, `brand_name`, `status_code`

 

 

EXPLAIN SELECT * FROM lic_s_0.`license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' and manufacturer_id = 'vivo' and model_id = 'PA2170' and status_code = 1 ORDER BY updated_at desc limit 1 ;

 可以看到const,const,const,const,   竟然有四个 const!  Extra 是Using index condition; Using filesort, 为什么是Using index condition; 而不是 Using index ? 因为SELECT *  并不能走覆盖索引。 为什么Using filesort ? 因为有 order by。。

虽然 limit 1 , 但是还是进行了排序。 why , 因为 limit 语句必须在 order by 后面执行, 所以 ,

 

 

继续

EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' and manufacturer_id = 'vivo' and model_id = 'PA2170' and brand_name = 'huawei' and status_code = 1 ;
EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' and manufacturer_id = 'vivo' and model_id = 'PA2170' ;
EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' and manufacturer_id = 'vivo' ;
EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' ;
EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' ;

EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' and manufacturer_id = 'vivo' and model_id = 'PA2170' and status_code = 1 ;
EXPLAIN SELECT app_id FROM `license_record2` where device_id = '00000000-016a-76e5-0000-000052c2195a' and status_code = 2 limit 1 ;
EXPLAIN SELECT app_id FROM `license_record2` where device_id = '00000000-016a-76e5-0000-000052c2195a' and status_code = 2 limit 1 ;
EXPLAIN SELECT app_id FROM `license_record2` where status_code = 2 limit 1

 

发现

EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' and manufacturer_id = 'vivo' and model_id = 'PA2170' and brand_name = 'huawei' and status_code = 1 ;

 

 

 竟然提示没有匹配的row 即行

 


EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' and manufacturer_id = 'vivo' and model_id = 'PA2170' ;

 

 

 

直接走了 index索引,ref  为4个const


EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' and manufacturer_id = 'vivo' ;

 

 

 直接走了 index索引,ref  为3

 


EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' ;

 

 

直接走了 index索引,ref  为2

可以看到 key 都是一样的, type 都是ref,key_len 快速的变小,同时 ref 从4 到3 到现在的2,


EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' ;

 

 

 同样的直接走了 index索引,不过为啥这次扫描的rows 这么多?  大概因为 相同app_id 为 20210525104140854 的有 12540行

 

EXPLAIN SELECT app_id FROM `license_record2` WHERE app_id = '20210525104140854' and device_id = '00000000-0691-d628-0000-00004394fc4f' and manufacturer_id = 'vivo' and model_id = 'PA2170' and status_code = 1 ;

 

 

 走了 index索引,ref  为4个const, 同时 使用了Using where; —— why ? 因为查询字段虽然有status_code ,但没有 brand_name , 断开了也不行, 无法走覆盖索引, 只能回表过滤查询, 即Using where 

 


EXPLAIN SELECT app_id FROM `license_record2` where device_id = '00000000-016a-76e5-0000-000052c2195a' and status_code = 2 limit 1 ;

 

 

 虽然 复合索引包括了device_id 、 status_code , key 也似乎用上了app_id, 但是 ref 为null,type为index,key_len 很长,扫描的rows  有12503240, 使用了回表过滤: Using where;

同时感觉所用了索引, Using index —— 但,不知道实际执行的时候会不会使用索引,感觉应该不会。

注意到 possible_keys ref 都是空, 说明什么?


EXPLAIN SELECT app_id FROM `license_record2` where device_id = '00000000-016a-76e5-0000-000052c2195a' and status_code = 2 limit 1 ;

同上,  重复了


EXPLAIN SELECT app_id FROM `license_record2` where status_code = 2 limit 1

同上, 少了device_id 字段并没有什么影响。

 

 

EXPLAIN select count(r.app_id)  from license_record2 r  where r.deleted != 1 

去掉 where条件:

 

 

 

 

 

 

 

 where 条件导致不走索引!

 

少了1, 有一行被删除!

 

 

参考:

https://cloud.tencent.com/developer/article/1093229

https://blog.51cto.com/ajisun/5222707

 

标签:app,actor,id,key,MySQL,type,EXPLAIN,SELECT
来源: https://www.cnblogs.com/FlyAway2013/p/16180437.html