1.被索引字段发生隐式转换
Mysql执行器在执行sql查询的时候，会自动将与原字段类型不匹配的值进行类型转换
我们创建如下表
image-20200427210417688.png
分别进行如下sql查询
explain select* from t_user where f_phone=139
image-20200427210513909.png
可以看到，key是null，也就是说索引是没有生效的，再换一种方式查询
explain select * from t_user where f_phone="139"
image-20200427210618184.png
此时，key为idx_phone也就是索引命中了。通过这个例子可以分析出，当被索引字段与原字段类型不匹配的时候，索引就会失效
2.被索引字段使用了表达式计算
还是使用t_user表，我们执行如下sql
explain select * from t_user where f_age-2=18;
image-20200427210638979.png
索引是没有被命中的，包括嵌套查询，索引页无法生效,比如如下sql
explain select * from t_user where f_age=(select f_age from t_user where f_phone='10086');
image-20200427211336945.png
可以看到，子查询2索引是生效的，同样age字段也是索引字段缺没有办法生效
3.被索引字段使用了函数
explain select * from t_user where left(f_age,1)='10086';
image-20200427211704880.png
小结：为什么这三种情况会导致索引失效呢？
因为索引字段是依赖于整个BTree索引树的遍历，而索引树遍历又依赖于索引树底层的叶子节点的有序性，当被索引字段进行了隐式转换，表达式计算，函数计算后，这个字段新的排列顺序和原来在索引树的叶子节点层的排列顺序不一样，破坏了叶子节点的有序性，mysql执行器无法判断原来的索引是否还能被检索，最后导致执行器不使用索引
4.在like关键字后使用了左模糊查询或者左右模糊查询
explain select * from t_user where f_phone like '%10086';
explain select * from t_user where f_phone like '%10086%';
image-20200427212448841.png
这两条查询语句索引都会失效，而使用右模糊查询，索引就会生效
explain select * from t_user where f_phone like '10086%';
image-20200427212612128.png
5.被使用的索引字段不是联合索引的最左字段
我们先创建name和phone字段的联合索引
image-20200427212810849.png
我们只对name做条件查询，如下
explain select * from t_user where f_name='小明';
image-20200427212936066.png
可以看出索引是不生效的，如果查询条件包含联合索引最左字段，则索引依然会生效
image-20200427213212889.png
小结：4、5情况，为什么索引会失效呢？
因为mysql索引树检索遵循最左匹配原则，因为叶 子节点有序性也是建立在最左匹配原则之上
最后，思考下，如下sql的索引会生效吗？原因又是什么呢？
explain select f_name,f_phone from t_user where f_name='小明';
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
答案是索引覆盖
