mysql面试：索引失效（一般什么情况下索引失效？如何查看索引是否失效）、sql优化（表的设计优化、union all和union的区别、join优化原理）、相关面试题回答模板

索引失效

首先我们执行计划explain，可以看到具体是否失效。
一般以下情况会索引失效：

• 违反最左前缀法则
• 使用了范围查询的列右边的列，索引失效
• 使用了运算操作的列， 索引失效
• 进行了类型隐式转换的列，索引失效
• 以%开头的Like模糊查询，索引失效

违反最左前缀法则

最左前缀法则指的索引创建时是用的多列索引，那么查询时就需要从索引的最左前列开始，并且不跳过索引中的列。譬如以下索引创建时用的是多列，从左到右为name、status、address。

那么观察以下三条查询语句的key和key_len，发现都命中了索引，因为key=‘tb_seller_index’，且每条语句的索引都没有失效，因为key_len分别为303，309，612，对应着查询条件从左往右一次增加。

图片1

但以下情况违反了最左前缀法则，可以看到key都为NULL了

图片2

如果符合最左法则，但是出现跳跃某一列，只有最左列索引生效。因为他和图片1的第一条查询的key_len一模一样，说明只有name生效，address没有生效。

图片3

使用了范围查询的列右边的列，索引失效

使用了范围查询的列本身索引生效，但是其右边的列会索引失效。
根据图片1中的第二条查询语句，发现和下面这条查询的key_len一样都是309，那么说明只有name和status索引生效了，address索引失效了。

图片4

进行运算操作的索引列失效

进行了隐式类型转换的索引列失效

以%开头的like模糊查询，索引失效

注意，如果只有%结尾的like模糊查询，索引依旧生效。
因为b+树是通过第一个字段的第一个字符的ascii码来排序的。

sql优化

一般sql优化的方向如下：

• 表的设计优化
• 索引优化
• SQL语句优化
• 主从复制、读写分离
• 分库分表

表的设计优化

表的设计可以参考阿里开发手册《嵩山版》（现在最新是黄山版）

比如设置合适的数值（tinyint int bigint），要根据实际情况选择
比如设置合适的字符串类型（char和varchar）char定长效率高，varchar可变长度，效率稍低。

sql语句优化

• SQL语句要避免造成索引失效的写法
• 注意union all和union的区别
• 避免在where子句中对字段进行表达式操作
• Join优化

union all和union的区别

一般来说union all不会去重，union会去重，所以效率会低一些。那么如果不需要去重，就尽量用union all代替union。

join优化

能用inner join 就不用left join或者right join，如果必须使用，小表最好放外层。因为内连接会对两个表进行优化，优先把小表放到外边，把大表放到里边。left join 或 right join，是不会重新调整顺序的。为什么把小表放到外边效率更高的原理就类似于两层循环，把循环次数较少的放在外层一样。是因为CPU会使用到分支预测技术，即以上一个的判断来预测下一个判断。循环次数越多，判断错误次数也会越多，放到内层的话可以降低判断错误的影响。

主从复制、读写分离

如果数据库的使用场景读操作比较多的时候，为了避免写的操作所造成的性能影响 可以采用读写分离的架构。一般开发阶段都会搭建读写分离的主从库的。

面试题回答模板

什么情况下索引会失效 ?

候选人：
嗯，这个情况比较多，我说一些自己的经验，以前遇到过的

比如，索引在使用的时候没有遵循最左匹配法则，第二个是，模糊查询，如果%号在前面也会导致索引失效。如果在添加索引的字段上进行了运算操作或者类型转换也都会导致索引失效。

我们之前还遇到过一个就是，如果使用了复合索引，中间使用了范围查询，右边的条件索引也会失效。

所以，通常情况下，想要判断出这条sql是否有索引失效的情况，可以使用explain执行计划来分析

创建表的时候，你们是如何优化的呢？

**候选人：**这个我们主要参考的阿里出的那个开发手册《嵩山版》，就比如，在定义字段的时候需要结合字段的内容来选择合适的类型，如果是数值的话，像tinyint、int 、bigint这些类型，要根据实际情况选择。如果是字符串类型，也是结合存储的内容来选择char和varchar或者text类型

那在使用索引的时候，是如何优化呢？

候选人：【参考索引创建原则 进行描述】

你平时对sql语句做了哪些优化呢？

候选人：嗯，这个也有很多，比如要注意SQL语句避免造成索引失效的写法；如果是聚合查询，尽量用union all代替union ，union会多一次过滤，效率比较低；如果是表关联的话，尽量使用inner join ，不要用left join或者right join，如果一定要使用，最好以小表为驱动。