1、带有运算
2、使用函数
3、使用%XXX左模糊查询,因为mysql是最左原则,使用XXX%右模糊查询是可以使用索引的,但是左模糊违背了最左原则所以不行
4、使用范围运算,not in,in > ,<都不行
5、查询的字段不是索引的最左字段,同样是因为最左原则
6、字段类型不匹配,常见的隐式数据类型转换,mobile=1356不会走索引,会转换为字符串可以查询但是,mobile='1356’会走索引
7、or条件左边的是索引字段,右边的不是。也不会走索引,因为or是一个并集
索引失效场景
在分析索引失效场景之前,我们必须要清楚索引结构的特点是什么。关于 Mysql 的数据库索引结构在之前的文章中已经进行了详细的分析,可以参见之前的文章。
这样理解Mysql索引,阿里面试官也给你点赞
我们再来看下 Mysql 数据库索引的结构特点:

本文以 user_info 这张表来作为分析的基础,在 user_info 这张表上,我们分别创建了 idx_name 以及 idx_phone 二级索引以及 idx_age_address 联合索引。
1、字段类型不匹配导致的索引失效
进行 SQL 数据查询的时候,where 条件字段类型与实际表中字段类型不匹配的时候,Mysql 会进行隐式的数据类型转换,而类型转换会使用到内置函数,导致在进行数据查询的时候并没有使用索引。我们可以使用 explain 命令查看 sql 语句。可以看的出来在 key 栏中,对应的值为 null,说明并没有使用索引进行查询。

但是如果在按照 phone_number 字段为字符串类型进行查询的时候,Mysql 没有进行隐式的类型转换,所以最终还是走了索引。

2、被索引字段使用了表达式计算
在 where 中条件使用了条件表达式的时候,数据表中的索引就失效了,实际是因为 Mysql 需要将索引字段取出来之后再进行表达式的条件判断,因而进行了全表扫描,导致索引失效。

3、被索引字段使用了内置函数
索引字段实际上是依赖于整个 B+索引树的遍历,而索引树的遍历又依赖于索引树底层叶子节点的有序性。索引保存的是索引列的原始值,如果经过函数计算,Mysql 的解释器无法判断计算后的索引在原来的索引树上是否可以被索引到,因此它就直接放弃使用索引查询了。

4、like 使用了 %X 模糊匹配
使用左模糊匹配以及左右模糊匹配都会导致索引失效,但是使用右模糊匹配,还是可以走索引查询的。

由于 B+树按照索引值进行排序的,实际是按照最左前缀进行比较,而使用了 %作为最左前缀,Mysql 无法判断其有序性,因此只能进行全表扫描查询。

5、索引字段不是联合索引字段的最左字段
如果数据库表中有联合索引的话,我们在 SQL 查询语句中使用的索引字段又不是联合索引的最左字段,那么就会导致索引失效。

实际上在 Mysql 中的索引检索是遵循最左匹配原则的,同时 B+索引树的叶子节点的有序性也是建立在最左匹配原则之上,而上述的 4、5 两种情况实际违反了最左匹配原则,因此 Mysql 执行器则无法使用对应的索引进行检查查询。

6、or 分割的条件,如果 or 左边的条件存在索引,而右边的条件没有索引,不走索引
因为 OR 的含义就是两个只要满足一个即可,因此只有一个条件列进行了索引是没有意义的,只要有条件列没有进行索引,就会进行全表扫描,因此索引的条件列也会失效。

7、in、not in 可能会导致索引失效

这里需要说明的是使用 in 以及 not in 走不走索引,实际和 Mysql 的版本以及表中的数据量有关系,在 8.0 之后的版本是走索引的。
注:此处加了地址的索引。
最后
深知大多数初中级Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《Java开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
小编已加密:aHR0cHM6Ly9kb2NzLnFxLmNvbS9kb2MvRFVrVm9aSGxQZUVsTlkwUnc==出于安全原因,我们把网站通过base64编码了,大家可以通过base64解码把网址获取下来。

本文探讨了Mysql索引在多种情况下的失效问题,包括字段类型不匹配、使用表达式计算、内置函数、like模糊匹配、非最左字段、OR条件和IN操作。了解这些场景有助于优化SQL查询,提高数据库性能。
424

被折叠的 条评论
为什么被折叠?



