MySQL 中的 like 关键字也能用索引吗?

我们常说,MySQL 中的 like 要慎用,因为会全表扫描,这是一件可怕的事!不过呢,也看情况,有的 like 其实也能用索引:有的时候 like 用索引效率很高,有的时候 like 虽然用了索引效率却低的可怕

我们一起来分析下。

最左匹配原则

我还是举个例子吧,假设我有如下一张表:

CREATE TABLE `user` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `birthday` date DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  `address` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `username` (`username`,`age`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

usernameage 组成了复合索引,复合索引名为 username,下文提到的 username 索引都是指该复合索引。

我们知道,对于如下 SQL:

select username,age from user2 where username='javaboy' and age=99;

这个 SQL 在查询的过程中,会用到覆盖索引,避免回表,提高查询效率。

那么现在问题来了,如果我单纯的只是想通过 username 字段查询用户呢,是否需要为 username 字段单独建立一个索引?

我们来看如下一条 SQL:

select username,age from user2 where username='javaboy';

由于我的表中没有为 username 字段建立的索引,那么它会不会使用已有的复合索引呢?我们来看下执行计划:

执行计划

可以看到,这里其实用到了 username 复合索引,通过 Extra 字段的值还能看到使用到了覆盖索引。

为啥会这样呢?在 B+Tree 这种索引结构中,可以利用索引的“最左匹配”来定位记录。最左匹配既可以是匹配复合索引中的前几个字段,也可以是匹配第一个字段的前几个字符,在上面的案例中,我们匹配的是复合索引中的第一个字段。

当然我们也可以匹配第一个字段的前几个字符,如下:

select username,age from user2 where username like 'j%';

执行计划如下:

执行计划

从这执行计划中首先可以确认这个查询也用到了 username 复合索引。

不过这里的查询计划和前面的不太一样,两条 SQL 的区别在于一个是等于号一个是模糊匹配,查询计划的主要区别在于 type 和 Extra:

  1. 前面的 type 为 ref 表示通过索引查找数据,一般出现等值匹配的时候,type 会为 ref;后面这个 type 为 range 表示这是一个索引的范围扫描(因为是模糊匹配,而模糊匹配可以形成扫描区间)。
  2. 前面的 ref 为 const 表示与索引列进行等值匹配的是一个常量。
  3. 前面的 Extra 为 Using index 表示使用到了覆盖索引;后面的 Extra 为 Using where;Using index,表示用到了索引,但是还需要进行过滤。

对于第一点中加粗的字体,我再来和大家多说两句。为什么说模糊匹配就能形成扫描区间呢?因为我们是按照 username 和 age 建立的复合索引,username 在前 age 在后,具体存的时候,是按照 username 排序存储,如果 username 相同,则按照 age 排序存储,结构类似下面这样:

username age
a 88
b 89
c 89
c 90
c 99
d 88
d 99

所以当想要搜索以 j 开头的 username 时,只需要定位到第一个以 j 开头的 username,然后利用 B+Tree 叶子结点之间的双向链表继续向后读取,读到第一个不是以 j 开头的 username 时截止,这就是扫描区间。

大家看到了,在上面的执行计划中,like 'j%' 其实也用到了索引,那么如果是 like '%j' 或者 like '%j%' 会用到索引吗?我们来看一个例子:

如果是 like '%j' 或者 like '%j%' 会用到索引吗?

咦!看执行计划似乎也用上索引了!难道只要字段上有索引,like 就能用索引?

当然不是!

大家来看下面这个辅助案例,看懂了就明白了。

辅助案例

为了让大家更好的理解上面所说的最左匹配,我们再来举一个例子。

还是上面的表和数据结构,但是现在假如我想按照 age 来做查询,SQL 如下:

select username from user2 where age=99;
select username from user2 where age>99;

我举了两个查询的例子,大家一起来看下这两条 SQL 的执行计划,其实没啥差异:

两条 SQL 的执行计划

这个查询计划我们该如何解释呢?其实这两个查询计划没啥区别,我就解释一个吧。

首先大家想一下,username 和 age 建立的是复合索引,username 在前 age 在后,具体在 B+Tree 中存储的时候,首先是按照 username 排序的,当 username 相同的时候,再按照 age 来排序,所以这个复合索引最终存储的结果就是,username 是有序的,而 age 是无序的,再来回顾下这个表格:

username age
a 88
b 89
c 89
c 90
c 99
d 88
d 99

username 是有序的,而 age 是无序的。

理解了这个,我们再来看这个执行计划就好懂了。

当我们按照 age 去搜索的时候,因为 age 在 username 索引中是无序的,所以只能遍历 username 索引,而执行计划中的 type 为 index,恰恰就表示需要扫描全部的索引记录。以第一条查询 SQL 为例,扫描全部的索引记录,然后过滤出 age 等于 99 的记录(过滤这一步是在 server 层完成的),rows 表示预估的扫描行数,从最后的 Extra 的 Using where;Using index 也能看出这一点,即用到了索引,但是也对数据进行了过滤。

回顾第一小节的最后 like '%j' 和 like '%j%' 的执行计划,不就是上面这个吗!

在前面这两条 SQL 中,因为我们查询的 username 字段已经存在于 username 索引中了,所以可以通过覆盖索引机制直接从索引中获取想要的数据并返回,不需要回表操作了。

推荐阅读:什么是 MySQL 的“回表”?

但是如果我们查询的字段不仅仅是索引中的字段,例如如下 SQL:

select * from user2 where age=99;

查询的是所有字段,那么此时就没有必要使用索引了,为啥?且听我细细道来。

我们来个反证:假设现在还是使用 username 复合索引,那么就需要把 username 索引整个读一遍,然后过滤出满足条件的数据,由于索引中没有保存 address 字段的值,所以还需要回表操作,再去主键索引中找到对应的记录。。。这一路操作下来太麻烦了,光 B+Tree 都读了两棵(而且第一颗 B+Tree 还是遍历),那我们还不如直接遍历主键索引呢!主键索引里要啥有啥,遍历完了想要的数据都有了,遍历主键索引其实就是我们常说的全表扫描。

小伙伴们仔细琢磨下上面这段话。

上面是我们的分析,接下来我们来看看执行计划:

执行计划

可以看到,如我们所想。

type 为 All 就是我们所熟悉的全表扫描(其实就是遍历主键索引),rows 是预估扫描的行数。最后的 Extra 为 Using where 表示 MySQL 首先从数据表(存储引擎)中读取记录,返回给 MySQL 的 server 层,然后在 server 层过滤掉不满足条件的记录。

总结

好啦,通过这样两个小案例,和大家分享了 MySQL 索引中的最左匹配原则,也希望小伙伴们能够借此理解索引的存储结构。

「点点赞赏,手留余香」

0

给作者打赏,鼓励TA抓紧创作!

微信微信 支付宝支付宝

还没有人赞赏,快来当第一个赞赏的人吧!

声明:
1. 本站所有文章教程及资源素材均来源于网络与用户分享或为本站原创,仅限用于学习和研究。
2. 如果内容损害你的权益请联系客服QQ:1642748312给予处理。
码云笔记 » MySQL 中的 like 关键字也能用索引吗?

发表评论

IT互联网行业相关广告投放 更专业 更精准

立即查看 联系我们