两类非常隐蔽的全表扫描,不能命中索引(一分钟系列)

简介: 两类隐蔽的不能利用索引的case:(1)表列类型,与where值类型,不一致;(2)join表的字符编码不同;

《MySQL死锁分析的两个工具》中,举了一个强制类型转换导致死锁的例子,有朋友询问是不是类型转换都不能命中索引,花1分钟细说一下。


第一类“列类型”与“where值类型”不符,不能命中索引,会导致全表扫描(full table scan)


数据准备

create table t1 (
cell varchar(3) primary key
)engine=innodb default charset=utf8;


insert into t1(cell) values ('111'),('222'),('333');


(1)cell属性为varchar类型;

(2)cell为主键,即聚簇索引(clustered index)

(3)t1插入3条测试数据;


测试语句

explain select from t1 where cell=111;
explain select
from t1 where cell='111';


(1)第一个语句,where后的值类型是整数(与表cell类型不符);

(2)第二个语句,where后的值类型是字符串(与表cell类型一致);


测试结果
image.png

(1)强制类型转换,不能命中索引,需要全表扫描,即3条记录;

(2)类型相同,命中索引,1条记录;

第二类相join的两个表的字符编码不同,不能命中索引,会导致笛卡尔积的循环计算(nested loop)


数据准备

create table t2 (
cell varchar(3) primary key
)engine=innodb default charset=latin1;


insert into t2(cell) values ('111'),('222'),('333'),('444'),('555'),('666');

create table t3 (
cell varchar(3) primary key
)engine=innodb default charset=utf8;


insert into t3(cell) values ('111'),('222'),('333'),('444'),('555'),('666');


(1)t2和t1字符集不同,插入6条测试数据;

(2)t3和t1字符集相同,也插入6条测试数据;

(3)除此之外,t1,t2,t3表结构完全相同;


测试语句

explain select from t1,t2 where t1.cell=t2.cell;
explain select
from t1,t3 where t1.cell=t3.cell;


(1)第一个join,连表t1和t2(字符集不同),关联属性是cell;

(2)第一个join,连表t1和t3(字符集相同),关联属性是cell;


测试结果
image.png

(1)t1和t2字符集不同,存储空间不同;

(2)t1和t2相join时,遍历了t1的所有记录3条,t1的每一条记录又要遍历t2的所有记录6条,实际进行了笛卡尔积循环计算(nested loop)索引无效

(3)t1和t3相join时,遍历了t1的所有记录3条,t1的每一条记录使用t3索引,即扫描1行记录;

画外音:图片请放大。


总结

两类隐蔽的不能利用索引的case:

(1)表列类型,与where值类型,不一致;

(2)join表的字符编码不同;

画外音:本文测试于MySQL5.6。作业

create table t1 (
cell varchar(3) primary key
)engine=innodb default charset=
utf8;


insert into t1(cell) values ('111'),('222'),('333');


create table t2 (
cell char(3) primary key
)engine=innodb default charset=
utf8;


insert into t2(cell) values ('111'),('222'),('333'),('444'),('555'),('666');

create table t3 (
cell int primary key
)engine=innodb default charset=
utf8;


insert into t3(cell) values (111),(222),(333),(444),(555),(666);


(1)t1, t2, t3的cell类型不同:分别是varchar(3), char(3), int;

(2)编码类型相同,均为utf8;


请问:t1与t2,t1与t3的join查询,能命中索引吗

explain select from t1,t2 where t1.cell=t2.cell;
explain select
from t1,t3 where t1.cell=t3.cell;


动动手,“实际结果”与“你以为的”,未必相同


希望这1分钟大家有收获,有思考,求帮转。

本文转自“架构师之路”公众号,58沈剑提供。

目录
相关文章
|
1月前
|
SQL Oracle 关系型数据库
分析索引失效的几种情况
联合索引 is not null 只要在建立的索引列(不分先后)都会走, in null时 必须要和建立索引第一列一起使用,当建立索引第一位置条件是is null 时,其他建立索引的列可以是is null(但必须在所有列 都满足is null的时候),或者=一个值; 当建立索引的第一位置是=一个值时,其他索引列可以是任何情况(包括is null =一个值),以上两种情况索引都会走。其他情况不会走。
60 1
|
1月前
|
SQL Oracle 关系型数据库
索引失效的情况分析
大家都知道,一条查询语句走了索引和没走索引的查询效率是非常大的,在我们建好了表,建好了索引后,但是一些不好的sql会导致我们的索引失效,下面介绍一下索引失效的几种情况
21 0
|
5天前
|
存储 关系型数据库 MySQL
【高频】什么是索引的下推和覆盖
【高频】什么是索引的下推和覆盖
|
7月前
|
存储 SQL Oracle
Oracle优化避免索引失效
Oracle优化避免索引失效
220 0
|
数据库 索引
MysSQL索引会失效的几种情况分析
MysSQL索引会失效的几种情况分析
130 0
MysSQL索引会失效的几种情况分析
|
存储 关系型数据库 MySQL
索引下推,这个点你肯定不知道!
索引下推(Index Condition Pushdown) ICP 是Mysql5.6之后新增的功能,主要的核心点就在于把数据筛选的过程放在了存储引擎层去处理,而不是像之前一样放到Server层去做过滤。 虽然这是一个比较简单的概念,但是可能很多不细心的同学对于索引下推会存在一个小小的误区,至于是什么,请看下文。
索引下推,这个点你肯定不知道!
|
存储 SQL 缓存
为什么索引可以让查询变快?终于有人说清楚了!
上表是一张真实的数据库表,其中每一行是一条记录,每条记录都有字段。假设上面的数据库是一个有10万条记录的大数据库。现在,我们想从10万条记录中搜索一些内容,那么挨着一个一个搜索无疑将花费很长的时间,这个时候我们在数据结构与算法里学的二分查找法就派上了用场。
为什么索引可以让查询变快?终于有人说清楚了!
|
SQL 索引

热门文章

最新文章