从根上理解SQL的like查询%在前为什么不走索引?

SQL herman 332浏览
公告:“业余草”微信公众号提供免费CSDN下载服务(只下Java资源),关注业余草微信公众号,添加作者微信:xttblog,发送下载链接帮助你免费下载!
本博客日IP超过1800,PV 2600 左右,急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包,请加博主新的微信号:xttblog,之前的微信号好友位已满,备注:返现
所有面试题(java、前端、数据库、springboot等)一网打尽,请关注文末小程序
视频教程免费领

我再次的阐述一下,用索引和走索引不是一个意思!

其实每天都有人私信我,如果遇到一些好的问题,我会拿来单独写文章的。比如,昨天就有人问我,like 查询 % 在前为什么不走索引?不能人云亦云,我们应该从根上理解它,为什么要这样设计?为什么不走索引?

其实结果对我来说,并不重要,重要的是过程。设计过程或者实现过程,这才是我最关心的。所以,今天我就从根上给你说一说为什么 like 查询 % 在前为什么不走索引?

例如,看这个例子:

SELECT * FROM xttblog WHERE name like '%xttblog';

说到这个例子,估计很多人会提到最左匹配原则。那么为什么要搞一个最左匹配原则呢?为什么不搞一个最右匹配原则?

这个问题,其实是和 B+Tree 有些关系,索引树从左到右都是有顺序的。对于索引中的关键字进行对比的时候,一定是从左往右以此对比,且不可跳过。

为什么是最左匹配原则?这个其实很好理解。比如,我们要比较一个字符串。xttblog 与 xmtblog,我们肯定是先从第一个字符开始比较吧,第一个相同后,再比较第二个字符,以此类推。所以要从左边开始,并且是不能跳过的。SQL 索引也是这样的。

然后,我们再来看标题中的问题。% 在前,就代表,我前面的内容不确定。不确定,我们怎么比较?只能一个一个的比较,那就相当于,全匹配了,全匹配就不需要索引,还不如直接全表扫描。

SQL 索引树结构图

在关键字比较的时候,会把字符串转换成 ascll 码,如 abc 变成 97 98 99,然后从左往右一个字符一个字符进行对比。like %xttblog 这个怪物,因为 % 表示全匹配,所以 MySQL 就放弃索引了,进行全表扫描。

后面,我再给你们讲讲,为什么说索引的离散型越高越好!

业余草公众号

最后,欢迎关注我的个人微信公众号:业余草(yyucao)!可加QQ1群:135430763(2000人群已满),QQ2群:454796847(已满),QQ3群:187424846(已满)。QQ群进群密码:xttblog,想加微信群的朋友,之前的微信号好友已满,请加博主新的微信号:xttblog,备注:“xttblog”,添加博主微信拉你进群。备注错误不会同意好友申请。再次感谢您的关注!后续有精彩内容会第一时间发给您!原创文章投稿请发送至532009913@qq.com邮箱。商务合作可添加助理微信进行沟通!

本文原文出处:业余草: » 从根上理解SQL的like查询%在前为什么不走索引?