本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
我再次的阐述一下，用索引和走索引不是一个意思！
其实每天都有人私信我，如果遇到一些好的问题，我会拿来单独写文章的。比如，昨天就有人问我，like 查询 % 在前为什么不走索引？不能人云亦云，我们应该从根上理解它，为什么要这样设计？为什么不走索引？
其实结果对我来说，并不重要，重要的是过程。设计过程或者实现过程，这才是我最关心的。所以，今天我就从根上给你说一说为什么 like 查询 % 在前为什么不走索引？
例如，看这个例子：
SELECT * FROM xttblog WHERE name like '%xttblog';说到这个例子，估计很多人会提到最左匹配原则。那么为什么要搞一个最左匹配原则呢？为什么不搞一个最右匹配原则？
这个问题，其实是和 B+Tree 有些关系，索引树从左到右都是有顺序的。对于索引中的关键字进行对比的时候，一定是从左往右以此对比，且不可跳过。
为什么是最左匹配原则？这个其实很好理解。比如，我们要比较一个字符串。xttblog 与 xmtblog，我们肯定是先从第一个字符开始比较吧，第一个相同后，再比较第二个字符，以此类推。所以要从左边开始，并且是不能跳过的。SQL 索引也是这样的。
然后，我们再来看标题中的问题。% 在前，就代表，我前面的内容不确定。不确定，我们怎么比较？只能一个一个的比较，那就相当于，全匹配了，全匹配就不需要索引，还不如直接全表扫描。
在关键字比较的时候，会把字符串转换成 ascll 码，如 abc 变成 97 98 99，然后从左往右一个字符一个字符进行对比。like %xttblog 这个怪物，因为 % 表示全匹配，所以 MySQL 就放弃索引了，进行全表扫描。
后面，我再给你们讲讲，为什么说索引的离散型越高越好！
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » 从根上理解SQL的like查询%在前为什么不走索引?