第一种 违反最左前缀法则
这个是针对联合索引的。
假设有个tb_seller表，现在给三个字段建立联合索引，建立的时候字段顺序不可随便设置，字段顺序： name, status, address。下图Seq_in_index对应的是联合索引顺序。
判断索引失效用explain执行计划， 不懂这个可以先看我另外一篇文章mysql定位慢查询以及分析原因-CSDN博客
最左前缀法则定义
如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列。匹配最左前缀法则，走索引：
现在如下图，根据最左前缀法则执行三个语句，来看看字段是否走索引。 解释一下key是实际用到的索引，key_len是索引占用的大小
第一条执行语句根据name查询，发现走了索引，并且索引长度为303.
第二条语句执行根据name和status查询，发现也走了索引，索引长度为309，证明name和status都走了索引。
第三条语句根据name、status、address查询，索引长度为612，证明三个都走了索引。
现在不按照最左原则试试，看看索引情况。
第一条语句根据status、address，直接跳过name，违反了最左原则中'最左前列开始'的条例。所以下面key为null，没走索引，那么查询就是全盘扫描，效率极低。
第二条只查status，和上面一样违反了原则，直接不走索引。
再来看一种情况，满足最左原则中'最左前列开始'的条例，但是中间跳过status，也就是违反'不跳过索引中的列'这个条例。我们可以看到索引是走了的，但是索引长度是303。
下面也是303，证明只有name走了索引，而address没走索引，索引失效了
第二种 范围查询右边的列索引失效
第一条查询是符合最左前缀原则，都走了索引，索引长度是612，作为正例，现在来看下一条。
第二条查询status用到了范围查询，明显索引失效了部分，索引长度只有309.
上图第二个查询语句和下面一样，就证明上图是是address索引失效了。
第三种 索引列上进行运算操作
可以看到我们对name进行了substring运算，结构key为null，索引失效。
第四种 字符串不加单引号，可能失效
对比下面两条语句，会发现第二条语句的status失效了。
原因：在查询时，没有对字符串加单引号，MySQL的查询优化器，会自动的进行类型转换，造成索引失效。也就是说类型转换才是索引失效的本质原因。任何类型转换都会导致索引失效。
第五种 模糊查询可能导致索引失效
注意这个可能
第一条、第二条查询语句name进行模糊查询，结果key为null，索引失效。
但第三条却没有。
结论： 以%开头的like模糊查询，索引失效。如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。