2.3.4. 索引失效

1. 对索引使用左或者左右模糊匹配

使用左或者左右模糊匹配的时候，也就是 like %xx 或者 like %xx% 这两种方式都会造成索引失效。但是如果前缀是确定的那么就可以使用到索引，例如 name like '许%'。

因为索引 B+ 树是按照「索引值」有序排列存储的，只能根据前缀进行比较。如果使用 name like '%许' 方式来查询，查询的结果可能是「小许、大许、老许」等之类的，存储引擎不知道从哪个索引值开始比较，于是就只能通过全表扫描的方式来查询。

1. 对索引使用函数

查询条件中对索引字段使用函数，就会导致索引失效。因为索引保存的是索引字段的原始值，而不是经过函数计算后的值，自然就没办法走索引了。

MySQL 5.7 开始，索引特性增加了函数索引，即可以针对函数计算后的值建立一个索引，也就是说该索引的值是函数计算后的值，所以就可以通过扫描索引来查询数据。

-- 对 length(name) 的计算结果建立一个名为 idx_name_length 的索引。
alter table t_user add key idx_name_length ((length(name)));

1. 对索引进行表达式计算

在查询条件中对索引进行表达式计算，也是无法走索引的。例如，下面代码

explain select * from t_user where id + 1 = 10;

如果把查询语句的条件改成 where id = 10 - 1，这样就不是在索引字段进行表达式计算了，于是就可以走索引查询了。

因为索引保存的是索引字段的原始值，而不是 id + 1 表达式计算后的值，所以无法走索引，只能通过把索引字段的取值都取出来，然后依次进行表达式的计算来进行条件判断，因此采用的就是全表扫描的方式。

个人觉得这种方式完全可以不使用没必要这么麻烦。

1. 对索引隐式类型转换

索引字段是字符串类型，查询条件种输入的参数是整型，在执行计划里发现这条语句会走全表扫描。

索引字段是整型类型，查询条件中的输入的参数是字符串，不会导致索引失效，还是可以走索引扫描。

-- 例1、索引是字符串 参数是整型
select * from t_user where phone = 1300000001;
-- 例2、索引是整型 参数是字符串
select * from t_user where id = '1';

因为MySQL 在遇到字符串和数字比较的时候，会自动把字符串转为数字，然后再进行比较。

-- 例1
select * from t_user where CAST(phone AS signed int) = 1300000001;-- 例2
select * from t_user where id = CAST("1" AS signed int);

例1，CAST 函数是作用在了 phone 字段，而 phone 字段是索引，也就是对索引使用了函数！

例2，索引字段并没有用任何函数，CAST 函数是用在了输入参数，所以可以走索引扫描的。

1. 组合索引非最左匹配

如果创建了一个 (a, b, c) 组合索引，因为有查询优化器，所以 a 字段在 where 子句的顺序并不重要。

如果查询条件是以下这几种，因为不符合最左匹配原则，所以就无法匹配上联合索引，联合索引就会失效:

• where b=2；
• where c=3；
• where b=2 and c=3；

比较特殊的查询条件：where a = 1 and c = 3 ，符合最左匹配吗？

MySQL 5.5 的话，前面 a 会走索引，在联合索引找到主键值后，开始回表，到主键索引读取数据行，Server 层从存储引擎层获取到数据行后，然后在 Server 层再比对 c 字段的值。

从 MySQL 5.6 之后，有一个索引下推功能，可以在存储引擎层进行索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，再返还给 Server 层，从而减少回表次数。

在组合索引的情况下，数据是按照索引第一列排序，第一列数据相同时才会按照第二列排序。

如果我们想使用联合索引中尽可能多的列，查询条件中的各个列必须是组合索引中从最左边开始连续的列。如果我们仅仅按照第二列搜索，肯定无法走索引。

1. WHERE 子句中的 OR

在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。只有一个条件列是索引列是没有意义的，只要有条件列不是索引列，就会进行全表扫描，所以需要两个条件都是索引列。