前言
一阵熟悉的起床闹钟响起,小菜同学醒来竟发现周围都是导致索引失效的原因:性感迷人的索引使用不当、可爱活泼的存储引擎无法识别索引列、刁蛮任性的优化器不选择索引...
知其然更要知其所以然,一起来看看索引为啥失效了吧~
在阅读文本前,需要知道聚簇索引、二级索引、回表等知识,如果同学不太了解可以去查看往期文章~
什么是索引失效呢?
对于MySQL常使用的索引来说,往往是聚簇索引和二级索引
索引失效指的是在某些场景下,MySQL不使用二级索引,而去使用聚簇索引(全表扫描),从而导致二级索引失效 (索引失效中的索引指的是二级索引)
不够熟悉索引导致使用不当
索引使用不当往往是因为我们不够了解索引
在聚簇索引中,记录按照主键值升序排序
在二级索引中,记录按照索引列、主键的顺序升序排序,当索引列相等时主键才有序
在(age,student_name)联合索引中,当age相等才对student_name排序,当student_name相等才对主键id排序
当我们熟悉索引存储规则之后,就可以有效避免索引使用不当的情况
比如 select * from student where student_name like 'c%'
是用不上(age,student_name)联合索引的
当查找的列不是有序的就可能会扫描整个二级索引,而这种情况下还可能要回表,因此MySQL会放弃使用二级索引,直接扫描聚簇索引,从而导致索引失效
当我们建立student_name索引后,上述SQL即可使用student_name二级索引
如果将SQL改为select * from student where student_name like '%c%'
也会导致无法使用索引
原因与上面说的类似,左模糊查询导致无法预估要扫描的区间,从而造成全表扫描
其他类似的场景还有order by
、group by
等需要排序场景,使用的二级索引不具备有序从而导致索引失效
当我们熟悉索引后一般场景下是不会犯这种索引使用不当的小错误~
存储引擎层导致索引失效
当执行器携带查询条件向存储引擎层请求数据时,如果存储引擎层无法识别数据也会导致无法使用索引
表达式
比如在查询条件中使用表达式 where age + 2 = 10
存储引擎层的innodb无法识别表达式时也会导致索引失效
当然我们一般不会采取这种写法(key_len = 3说明只用到联合索引中的age)
函数
当我们对索引列使用函数时,存储引擎层也无法识别
比如 explain select * from student where age = '8' limit 1000
会隐式使用函数将'8'
由字符串转换为整形8
等同于该SQL SELECT * FROM student WHERE age = CAST('8' AS UNSIGNED) LIMIT 1000
这种情况下是可以使用索引的
当对索引列age
使用函数时如:SELECT * FROM student WHERE CAST(age AS CHAR) = '8' LIMIT 1000
存储引擎层无法识别CAST(age AS CHAR)
导致无法使用age相关的索引
隐式使用函数进行类型转换也是容易导致索引失效的一种场景
即使字段类型相同也有可能发生隐式类型转换,比如 utf8(mb3) 向 utf8mb4 进行转换
在联表查询中,一般会为被驱动表的关联条件建立索引加速查询
select a2,b1 from a
left join b on a.a2 = b.b2
比如在这个SQL中b为被驱动表,为关联条件需要的b2建立索引可以加快查询
正常情况下会使用索引(上图)
但是同样的SQL,你知道什么情况下会变成下图这样吗?
虽然用上了索引但没完全用上,还是使用了join buffer,从前后的key_len也可以知道没完全用上
原因就是当a2字段的字符集为uft8mb4、b2为utf8时,从驱动表a获取记录去被驱动表b中获取,b2字段隐式使用函数转换为utf8mb4导致存储引擎无法识别
菜菜就因为这种情况在本地没问题,结果生产上字符集不同导致索引失效
Server层导致索引失效
另一种索引失效的场景发生在server层:当优化器认为使用该索引成本太大则会偏向使用全表扫描
回表太多
那么啥情况会让优化器认为使用二级索引成本大呢?
使用二级索引时往往是需要回表导致成本大
因为回表不止需要多查询一个聚簇索引,由于二级索引的主键值可能无序查询聚簇索引时还会导致随机IO
回表成本大的场景一般发生在查询数据量较大的情况下,因为回表的数据增多成本也就变大
MySQL认为使用二级索引成本太大从而导致索引失效
比如or、is null、is not null
等查询条件并不一定会导致索引失效,当MySQL预估它们的数据量太大回表开销太高时才会放弃使用二级索引
又或者是深分页问题 limit 10000000,10
,由于MySQL要在server层进行limit,那就会导致先查前一千万条数据,而使用查的数据量太大,如果需要回表成本就会非常高,从而导致深分页问题的索引失效
估算误差用错索引
当MySQL估算成本估算错误时也可能导致索引失效
当需要扫描的记录数量超过一定限制(show variables like 'eq_range_index_dive_limit'
)时,会使用统计的方式预估成本容易有误差(空闲时使用analyze table 重新统计cardinality)
cardinality用于判断重复值,越小说明重复值越多,如果重复值太多(cardinality太小),也会让MySQL不偏向使用索引
总结
索引失效大致分为3种场景:索引使用不当、存储引擎层导致索引失效、Server层导致索引失效
不熟悉索引存储规则,在使用时就容易造成索引使用不当,如:左模糊匹配、联合索引最左匹配原则、order by、group by排序等
当存储引擎层无法识别查询条件中的索引列时会导致索引失效,如:索引列使用表达式、显示/隐式使用函数等
当Server层优化器认为使用二级索引成本太大时会导致索引失效,成本的主要来源是回表,回表数据量太大就会导致成本高而不偏向使用索引,如深分页问题等(重复值太多也会导致不偏向使用索引)
当需要扫描的记录数量超过一定限制,使用统计预估成本会造成误差,误差过大也会造成索引失效
最后(不要白嫖,一键三连求求拉~)
小菜同学熟悉各种场景导致的索引失效后,准备将周围的索引失效场景一一攻略
一阵熟悉的起床闹钟响起,小菜同学满头大汗的爬起:原来只是一场梦,还好项目里没有这么多索引失效的场景
本篇文章被收入专栏 由点到线,由线到面,构建MySQL知识体系,感兴趣的同学可以持续关注喔
本篇文章笔记以及案例被收入 gitee-StudyJava、 github-StudyJava 感兴趣的同学可以stat下持续关注喔~
有什么问题可以在评论区交流,如果觉得菜菜写的不错,可以点赞、关注、收藏支持一下~
关注菜菜,分享更多干货,公众号:菜菜的后端私房菜
标签:导致,age,MySQL,完蛋,索引,student,使用,失效 From: https://blog.51cto.com/u_16248875/8441884本文由博客一文多发平台 OpenWrite 发布!