MySQL 索引失效-模糊查询，最左匹配原则，OR条件等。( 三 ) _生活百科

然后我再用下面这条查询语句，这时候就会走索引了。

文章插图
对索引进行表达式计算在查询条件中对索引进行表达式计算，也是无法走索引的。
比如，下面这条查询语句，执行计划中 type = ALL，说明是通过全表扫描的方式查询数据的：
explain select * from t_user where id + 1 = 10;

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

文章插图

为什么对索引进行表达式计算，就无法走索引了呢？

原因跟对索引使用函数差不多。
因为索引保存的是索引字段的原始值，而不是 id + 1 表达式计算后的值，所以无法走索引，只能通过把索引字段的取值都取出来，然后依次进行表达式的计算来进行条件判断，因此采用的就是全表扫描的方式。
有的同学可能会说，这种对索引进行简单的表达式计算，在代码特殊处理下，应该是可以做到索引扫描的，比方将id + 1 = 10 变成 id= 10 - 1 。
是的，是能够实现，但是 MySQL 还是偷了这个懒，没有实现。
我的想法是，可能也是因为，表达式计算的情况多种多样，每种都要考虑的话，代码可能会很臃肿，所以干脆将这种索引失效的场景告诉程序员，让程序员自己保证在查询条件中不要对索引进行表达式计算。
对索引隐式类型转换如果索引字段是字符串类型，但是在条件查询中，输入的参数是整型的话，你会在执行计划的结果发现这条语句会走全表扫描。
我在原本的 t_user 表增加了 phone 字段，是二级索引且类型是 varchar 。
然后我在条件查询中，用整型作为输入参数，此时执行计划中 type = ALL，所以是通过全表扫描来查询数据的。
select * from t_user where phone = 1300000001;但是如果索引字段是整型类型，查询条件中的输入参数即使字符串，是不会导致索引失效，还是可以走索引扫描。
我们再看第二个例子， id 是整型，但是下面这条语句还是走了索引扫描的。
explain select * from t_user where id = '1';

文章插图

为什么第一个例子会导致索引失效，而第二例子不会呢？

要明白这个原因，首先我们要知道 MySQL 的数据类型转换规则是什么？就是看 MySQL 是会将字符串转成数字处理，还是将数字转换成字符串处理。
我在看《mysql45讲的时候》看到一个简单的测试方式，就是通过 select “10” > 9 的结果来知道MySQL 的数据类型转换规则是什么：

如果规则是 MySQL 会将自动「字符串」转换成「数字」，就相当于 select 10 > 9，这个就是数字比较，所以结果应该是 1；
如果规则是 MySQL 会将自动「数字」转换成「字符串」，就相当于 select "10" > "9"，这个是字符串比较，字符串比较大小是逐位从高位到低位逐个比较（按ascii码），那么"10"字符串相当于 “1”和“0”字符的组合，所以先是拿 “1” 字符和 “9” 字符比较，因为 “1” 字符比 “9” 字符?。越峁Ω檬?0 。

在 MySQL 中，执行的结果如下图：

文章插图
上面的结果为 1，说明 MySQL 在遇到字符串和数字比较的时候，会自动把字符串转为数字，然后再进行比较。
前面的例子一中的查询语句，我也跟大家说了是会走全表扫描：
//例子一的查询语句select * from t_user where phone = 1300000001;这是因为 phone 字段为字符串，所以 MySQL 要会自动把字符串转为数字，所以这条语句相当于：
select * from t_user where CAST(phone AS signed int) = 1300000001;可以看到，CAST 函数是作用在了 phone 字段，而 phone 字段是索引，也就是对索引使用了函数！而前面我们也说了，对索引使用函数是会导致索引失效的。
例子二中的查询语句，我跟大家说了是会走索引扫描：
//例子二的查询语句select * from t_user where id = "1";这时因为字符串部分是输入参数，也就需要将字符串转为数字，所以这条语句相当于：