前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >从根上理解SQL的like查询%在前为什么不走索引?

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

作者头像
业余草
发布2019-07-10 14:50:14
4.9K0
发布2019-07-10 14:50:14
举报
文章被收录于专栏:业余草业余草

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

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

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

例如,看这个例子:

640?wx_fmt=png
640?wx_fmt=png

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

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

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

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

640?wx_fmt=png
640?wx_fmt=png

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

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

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019年07月08日,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL(TencentDB for MySQL)为用户提供安全可靠,性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性,包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL,可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理,不仅经济实惠,而且稳定可靠,易于运维。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档