一、问题
1.一条SQL引出的问题
//in里面大概有三四十编号吧
select * from table where no in (123455,12346,12349.....)
no是建了索引的，但是通过执行计划发现type值为ALL，没有命中索引，然后查看no的字段类型是varchar，我in里面是数字类型的值，就大概知道原因了。
2.解决方案
在in中为每个值加上单引号''，通过值计划发现type值为ref，证明命中了索引(ref是命中非唯一索引)
3.原因
经过一番查资料并验证得知，是因为字段类型隐式转换导致的，我是怎么验证隐式转换的过程呢，如下：
select 1='1' //结果为1，也就是相等
select '1ab'=1 //结果为1，也是相等
select 'ab'=1//结果为0，不想等
通过上面语句得知，字符串和数字比较的时候，会将字符串转换成数字，然后比较
mysql的数据转换函数就两种
- cast(value as type)
- convert(value,type)
两个函数执行效果一样，只是参数不同，这里的type和数据库的字段类型是有差异的，type有如下几种：
- binary：二进制类型；
- char：字符类型；
- date：日期类型；
- time：时间类型；
- datetime：日期时间类型；
- decimal：浮点型；
- signed：整型；
- unsigned：无符号整型；
select cast('1ab' as signed) //结果为1
select cast('ab1' as signed) //结果为0
select cast('12a13b' as signed) //结果为12
类型转换函数会将字符串首位的数字截取并转换为整数，若首位是字母开头则转为0，也就明白了刚刚上面等号两边的判断原理了。
二、索引失效场景
当然了，索引失效不止我上面这一种，当搞清楚一个问题背后的原理的时候，除了问题得到答案，你也会收获的更多。
为大家介绍6种会发生索引失效的情况：
- 当我们使用like查询的时候，左匹配或左右匹配也就是like '%xxx'或者like '%xxx%'，都会造成索引失效（除非这个表里的字段全部都是索引～～）
- 当我们在查询条件中对索引列使用函数，会导致索引失效
- 字符串和数字比较时，会自动把字符串转为数字，然后再进行比较，如果字符串是索引列，而条件语句中的参数是数字的话，那么索引列会发生隐式转换，由于隐式转换是通过cast函数实现，等同于对索引列使用了函数，导致索引失效（也就是我碰到的问题）
- 联合索引要能正确使用需要遵循最左匹配原则，也是按照最左优先的方式进行索引匹配，否则就会导致索引失效
- 在where语句中，如果在or前的条件列是索引列，而在or后的条件列不是索引列，那么索引会失效
