我在面试中遇到过这样一个问题: 除了not in , or ,like前模糊 有索引失效的情况,还有哪些索引? 我.... 对于一个整天游荡在产品,测试中间来回穿梭的人并没有过多的关注这些,导致面试没有回答上来,下面我给大家总结了几点可以吊打面试官的几点:

在用联合索引进行排序时:

(1) ASC、DESC不能混用,混用的话会导致索引失效。

因为联合索引在底层存储非叶子节点列值的时候是按照联合索引建立时候的顺序进行排序的,可以参考我另一篇文章<面试官: 为啥要满足最左前缀原则?> 来进行理解。

(2) 排序列包含非同一个索引的列,会导致索引失效

因为根据不同的索引,建立了不同的索引树来存储数据,所以无法在同一个索引树上完成排序,来提升查询的效率。

(3) 排序列是某个联合索引的索引列,但是这些排序列在联合索引中并不连续,会导致索引失效。

可以参考我的另一篇文章<面试官: 为啥要满足最左前缀原则?>key_part1和key_part3在联合索引idx_key_part中并不连续,中间还有一个key_part2,所以对于idx_key_part的二级索引记录来说,key_part1值相同的记录并不是按照key_part3排序的,所以不能使用联合索引idx_key_part来完成排序。

(4) 用来形成的扫描区间的索引列与排序列不同

比如下面这个查询语句:

select * from single_table where key1 = "a" order by key2 limit 10;

其中key1,key2分别有单独的索引

通过key1= "a" 来形成的扫描区间,并不能通过索引key2来执行上述查询

(5) 排序列不是以单独的列名出现在order by 子句中

要想使用索引列进行排序操作,必须保证索引列是单独的列名形式(而不是修饰过的形式)出现,比如下面这个查询语句:

select * from single_table order by UPPER(key1) limit 10;

这里通过函数UPPER将字符串转为大写的形式并不能使用到索引。