【生产问题】mysql死锁和分库分表问题
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了【生产问题】mysql死锁和分库分表问题，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4200字，纯文字阅读大概需要7分钟。
内容图文
记录生产mysql的问题点。
业务场景与问题描述
请求一个外部接口时，每天的请求量在900万左右。
分为请求项目和回执这两个项目。请求是用来调用外部接口，回执是接收发送的接口。
在发送请求前会先插入数据库。
在请求后，如果接口返回调用失败，会更新数据库状态为失败。
如果发送成功，则会等待上游给出回执消息后，然后更新数据库状态。
而在生产运行过程中，半年出现过两次mysql导致的mq消费者堆积的问题。
问题分析
记录两次不同的原因导致的生产问题及原因分析。
mysql死锁问题
查看mq聚合平台TPS
上生产发现mq数据一直堆积，且不断上升。而TPS仅为30左右，一直上不去。
这就会使mq消费变慢了，导致不断堆积。具体什么原因导致mq一直堆积，需要继续排查。
查看生产服务器日志
查看生产服务器日志，发现有报错dead Lock的错误。
error response from MySQLConnection [node=24, id=277499, threadId=2735941, state=borrowed, closed=false, autocommit=true, host=10.1.10.74, port=3306, database=sep_4, localPort=27744, isClose:false, toBeClose:false, MySQLVersion:5.7.25], err: Deadlock found when trying to get lock; try restarting transaction, code: 1213
具体的sql如下：
update stage set status = 'success',reply_time = '2021-03-07 10:40:11' where code = '000123' and create_time > '2021-03-03 00:00:00';
也就是说在执行服务时出现了死锁的情况。
具体有多少条以及耗时，在生产服务器看着不直观，于是就让dba将慢sql的语句和耗时查出来。
查出后发现最长的慢sql的耗时长达7780ms。
仔细查看会发现，sql会发现相同的id一个在执行中，一个在Lock Wait状态。
而这慢sql中有大量的Lock Wait状态。
什么原因导致的死锁
mysql使用的数据库引擎时InnoDB。先了解下什么是死锁：
所谓死锁: 是指两个或两个以上的进程在执行过程中,
因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.
此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等竺的进程称为死锁进程.
通过上面的排查可以看出，出现死锁的问题就是：
在执行sql更新一条数据时，会将这一行数据锁定，执行完成后会释放行锁，而没有执行的sql处于Lock Wait状态。
而程序中导致此原因在于，在发送前后和回执时，频繁操作数据库，可能会出现同时操作同一条数据的情况。
所以在执行中就出现了锁等待的情况。
分库分表未带分片键
首先告警的是stage_prod库的CPU飙到了85%。
数据库线程数是否被打满
经过查看数据库连接情况可知，数据库连接数并没有被占满。
查出慢sql和耗时
查出的问题sql：
update stage set status = 'success',reply_time = '2021-03-07 10:40:11' where create_time > '2021-03-03 00:00:00';
查看sql会发现，这条sql竟然没有带分片键code字段。而这条sql是回执时执行的。
排查生产服务器日志
代码中有做判断，如果code值不为空，sql会带上code的值。那么没带上，就需要查看为何没有带上。
查看代码会发现，code是从redis中获取的，是在发送时set到redis中的。但是没有set进去就很奇怪了。
初步怀疑是redis问题，然后就与redis维护的平台沟通，发现果真是因为redis故障导致的问题。
为什么不带分片键CPU就会飙升
首先公司用的是hotdb分库分表，因为每天的入库量是在900万左右，一个表是上亿条数据。
如果只是单纯用索引，是无法满足要求的。
分库分表hotdb，根据code值做hash分片，做了64个分片。也就是说64个数据库，分布在8台服务器上的16个实例里面。
这样可以避免各分片数据不均，理论上避免了过度集中在某个分片上。
而如果不带分片键code的sql，所有的dml操作全部下发到所有的底层库上进行执行，相当于遍历了一遍库。
这样就可能会导致CPU直接飙到99%，甚至直接导致服务器直接崩掉，这样操作是很可怕的。
解决办法
应急处理：先停掉几台服务减少数据库操作
数据持续堆积，会影响数据处理速度。那么，就要先降低操作的速度，最快速的办法就是停服务，减少数据库的操作频率。
减少数据库操作避免数据库死锁
死锁一般时由于程序上没有控制好dml操作的提交，没有及时提交.
减少重复操作同一条数据。在批量操作时减少每批dml数，保证快速提交，避免长事务，避免重复提交dml。
那么怎样减少操作呢？
合并sql
将发送前插入和发送失败时更新，直接合并到一条sql，这样就可以避免多次操作同一条数据的情况。
批量执行时减少长事务和条数
执行时发现，每次批量执行20条sql，比一次性执行200条的效率更快。
所以尽可能避免这种问题。
每条sql必须带分库分表分片键
原则就是不能因为一条数据就拖累整个数据库的操作速度。
分片键必须带上，如果不带分片键，就抛错。
增加时间区间开闭区间
用code来做分片键，用createTime做分区。那么在保证code存在的情况下，可以写上开闭区间，可以提高执行效率。
更优解：sql顺序执行
这种方案可以通过把将要执行的sql统一发到一个mq来消费执行，这样可以保证sql顺序执行，从而避免死锁的产生。
但是这个需要根据业务场景来区分。
复盘
- mysql死锁问题，要尽可能避免频繁操作同一条数据，也要避免长事务；
- 针对分库分表问题，一定要带上分片键；
- 监控机制不可少；
内容总结
以上是互联网集市为您收集整理的【生产问题】mysql死锁和分库分表问题全部内容，希望文章能够帮你解决【生产问题】mysql死锁和分库分表问题所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。