mysql联合索引注意事项,解决为啥联合索引无效的问题

在数据查询的时候合理利用索引才更好地提高查询效率。今天遇到一个数据量不算太大(1000万左右)的表,但是查询特别慢,建立了userid,logtype,fromid 发现索引无效,查阅相关资料后发现联合索引需要注意一下问题,顺序和使用条件非常关键。

参考下面的讲解:

对于复合索引:Mysql从左到右的使用索引中的字段,一个查询可以只使用索引中的一部份,但只能是最左侧部分。例如索引是key index (a,b,c)。 可以支持a | a,b| a,b,c 3种组合进行查找,但不支持 b,c进行查找 .当最左侧字段是常量引用时,索引就十分有效。

 

    利用索引中的附加列,您可以缩小搜索的范围,但使用一个具有两列的索引不同于使用两个单独的索引。复合索引的结构与电话簿类似,人名由姓和名构成,电话簿首先按姓氏对进行排序,然后按名字对有相同姓氏的人进行排序。如果您知道姓,电话簿将非常有用;如果您知道姓和名,电话簿则更为有用,但如果您只知道名不姓,电话簿将没有用处。

    所以说创建复合索引时,应该仔细考虑列的顺序。对索引中的所有列执行搜索或仅对前几列执行搜索时,复合索引非常有用;仅对后面的任意列执行搜索时,复合索引则没有用处。

    如:建立 姓名、年龄、性别的复合索引。

    create table myTest(

         a int,

         b int,

         c int,

         KEY a(a,b,c)

    );

(1)    select * from myTest  where a=3 and b=5 and c=4;   ----  abc顺序
abc三个索引都在where条件里面用到了,而且都发挥了作用


(2)    select * from myTest  where  c=4 and b=6 and a=3;
where里面的条件顺序在查询之前会被mysql自动优化,效果跟上一句一样


(3)    select * from myTest  where a=3 and c=7;
a用到索引,b没有用,所以c是没有用到索引效果的


(4)    select * from myTest  where a=3 and b>7 and c=3;     ---- b范围值,断点,阻塞了c的索引
a用到了,b也用到了,c没有用到,这个地方b是范围值,也算断点,只不过自身用到了索引


(5)    select * from myTest  where b=3 and c=4;   --- 联合索引必须按照顺序使用,并且需要全部使用
因为a索引没有使用,所以这里 bc都没有用上索引效果


(6)    select * from myTest  where a>4 and b=7 and c=9;
a用到了  b没有使用,c没有使用


(7)    select * from myTest  where a=3 order by b;
a用到了索引,b在结果排序中也用到了索引的效果,a下面任意一段的b是排好序的


(8)    select * from myTest  where a=3 order by c;
a用到了索引,但是这个地方c没有发挥排序效果,因为中间断点了,使用 explain 可以看到 filesort


(9)    select * from mytable where b=3 order by a;
b没有用到索引,排序中a也没有发挥索引效果

2.索引失效的条件
不在索引列上做任何操作(计算、函数、(自动or手动)类型转换),会导致索引失效而转向全表扫描
存储引擎不能使用索引范围条件右边的列
尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致)),减少select *
mysql在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描

is null,is not null也无法使用索引   ----  此处存在疑问,经测试确实可以使用,ref和const等级,并不是all

ike以通配符开头(’%abc…’)mysql索引失效会变成全表扫描的操作。问题:解决like‘%字符串%’时索引不被使用的方法?

按照上面的方式,我把索引修改了,修改后发现命中率很高,匹配非常快,秒回,将查询十几秒优化到了1秒内



评论/留言