完蛋!😱 我被MySQL索引失效包围了!

前言

一阵熟悉的起床闹钟响起,小菜同学醒来竟发现周围都是导致索引失效的原因:性感迷人的索引使用不当、可爱活泼的存储引擎无法识别索引列、刁蛮任性的优化器不选择索引...

知其然更要知其所以然,一起来看看索引为啥失效了吧~

在阅读文本前,需要知道聚簇索引、二级索引、回表等知识,如果同学不太了解可以去查看往期文章~

什么是索引失效呢?

对于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 bygroup 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 进行转换

在联表查询中,一般会为被驱动表的关联条件建立索引加速查询

css 复制代码
 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-StudyJavagithub-StudyJava 感兴趣的同学可以stat下持续关注喔~

有什么问题可以在评论区交流,如果觉得菜菜写的不错,可以点赞、关注、收藏支持一下~

关注菜菜,分享更多干货,公众号:菜菜的后端私房菜

相关推荐
好奇的菜鸟18 分钟前
如何在IntelliJ IDEA中设置数据库连接全局共享
java·数据库·intellij-idea
tan180°19 分钟前
MySQL表的操作(3)
linux·数据库·c++·vscode·后端·mysql
DuelCode1 小时前
Windows VMWare Centos Docker部署Springboot 应用实现文件上传返回文件http链接
java·spring boot·mysql·nginx·docker·centos·mybatis
优创学社21 小时前
基于springboot的社区生鲜团购系统
java·spring boot·后端
why技术1 小时前
Stack Overflow,轰然倒下!
前端·人工智能·后端
幽络源小助理1 小时前
SpringBoot基于Mysql的商业辅助决策系统设计与实现
java·vue.js·spring boot·后端·mysql·spring
Hello.Reader2 小时前
Redis 延迟排查与优化全攻略
数据库·redis·缓存
ai小鬼头3 小时前
AIStarter如何助力用户与创作者?Stable Diffusion一键管理教程!
后端·架构·github
简佐义的博客3 小时前
破解非模式物种GO/KEGG注释难题
开发语言·数据库·后端·oracle·golang
爬山算法3 小时前
MySQL(116)如何监控负载均衡状态?
数据库·mysql·负载均衡