MySQL索引优化实践

1 联合索引最左前缀法则


create index n_a_p_index on person(name,age,phone)

如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列。


explain select * from person where name = '小明' and age = 11 and phone = '11'

使用了索引n_a_p_index，索引长度为143


explain select * from person where name = '小明' and age = 11

使用了索引n_a_p_index，索引长度也为44,这说明phone上的索引长度为99


explain select * from person where name = '小明'

使用了索引n_a_p_index，索引长度为39，这是说明name上的索引长度为39，age上的索引长度为5


explain select * from person where   name = '小明' and phone = '11'

使用了索引n_a_p_index，索引长度也为39,这说明phone索引失效了，这是因为我们跳过了age


explain select * from person where age = 11 and phone = '11'

注意 name，age和phone位置摆放不影响上面的结果

结论：只有最左索引在，索引就会生效，单如果跳跃某一列，后面的索引就不是有序的，所以会失效。

2 联合索引范围查询

联合索引中，出现范围查询（>，<），范围查询右侧的列索失效


explain select * from person where name = '枫翎一中' and age > 22 and phone = '11111'

如果我们想要phone上的索引生效，我们可以使用>=，如下。注意，这种优化有时可能是无效的，因为mysql内部有他自己的索引评估优化。


explain select * from person where name = '枫翎一中' and age >= 22 and phone = '11111'

3 不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描

因为如果在索引列上进行运算操作，那么其计算的值和不是b+tree中节点的值，不能进行查询


explain select * from person where  substring(home,2) = '海'

4 字符串类型索引使用时，不加引号，索引将失效

字符串类型索引使用时，不加引号进行查找时，mysql底层会把字段进行string计算


create index home_index on person(home)

先加引号


explain select * from person where home = '11'

不加引号


explain select * from person where home = 11

5 头部模糊匹配，索引失效，会变成全表扫描操作

like KK%相当于=常量，%KK和%KK% 相当于范围

索引使用时，如果仅仅是尾部模糊匹配，索引不会失效。


explain select * from person where  home like '上%'

如果是头部模糊匹配，索引失效。


explain select * from person where  home like '%上'

下面在来个思考题，下面age和phone会走索引么？

create index n_a_p_index on person (name, age, phone);explain select * from person where  name like '小明%' and age = 11 and phone = '1'

会？那这是为什么呢？正常情况按照最左前缀原则，这种情况只会走name字段索引，因为根据name字段过滤完，得到的索引行里的age和 phone是无序的，无法很好的利用索引。

在MySQL5.6之前的版本，这个查询只能在联合索引里匹配到名字是 ‘小明’ 开头的索引，然后拿这些索引对应的主键逐个回表，到主键索引上找出相应的记录，再比对age和phone这两个字段的值是否符合。

MySQL 5.6引入了索引下推优化，可以在索引遍历过程中，对索引中包含的所有字段先做判断，过滤掉不符合条件的记录之后再回表，可以有效的减少回表次数。使用了索引下推优化后，上面那个查询在联合索引里匹配到名字是 ‘小明’ 开头的索引之后，同时还会在索引里过滤age和phone这两个字段，拿着过滤完剩下的索引对应的主键id再回表查整行数据。

索引下推会减少回表次数，对于innodb引擎的表索引下推只能用于二级索引，innodb的主键索引（聚簇索引）树叶子节点上保存的是全行数据，所以这个时候索引下推并不会起到减少查询全行数据的效果。

为什么范围查找Mysql没有用索引下推优化？我猜应该是Mysql认为范围查找过滤的结果集过大，like KK% 在绝大多数情况来看，过滤后的结果集比较小，所以这里Mysql选择给 like KK% 用了索引下推优化，当然这也不是绝对的，有时like KK% 也不一定就会走索引下推。

6 or连接

home和school上有索引，phone没有

or连接的条件，如果or一条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。

explain select * from person where  phone = '1111' or home =  '上海'
explain select * from person where  home =  '上海' or phone = '1111'

除非都2个条件列都有索引


explain select * from person where  school = '北京大学' or home =  '上海'

7 MySQ索引评估

如果MySQ评估使用索引比全表更慢，则不使用索引。如下


explain select * from person where  home is not null

因为表中home都有值


explain select * from person where  home is  null

注意如果我把home值都变为null，上面的结果会相反，这就是MySQ的索引评估

索引设计原则

1.针对于数据量较大，且查询比较频繁的表建立索引。

2.针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引。

3.尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。

4.如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。

5.尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率。

6.要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。

7.如果索引列不能存储NULL值，请在创建表时使用NOT NU儿L约束它。当优化器知道每列是否包含NU儿L值时，它可以更好地确定哪个
索引最有效地用于查询。