mysql 事务一直running_事务一直running?记录一次事务异常导致的下单阻塞

本文描述了一次由于定时任务引发的MySQL事务阻塞问题,导致下单接口长时间无响应。通过检查发现,一个长时间运行的事务持有行锁,影响了新的下单事务。解决方案是将定时任务中的大事务拆分为队列处理,减少锁竞争,从而避免类似问题的发生。
摘要由CSDN通过智能技术生成

场景:同事在处理下单流程的时候,突然发现请求接口没有反应,一直处于阻塞状态。

在检查具体的业务代码之后,发现并没有明显的错误。

思来想去,再次把目光投向了MySQL上面。第一步,先检查了一下是否有一直执行中的事务。

起初怀疑,嵌套事务的写法的saveapoint会不会对事务的执行造成影响,后面调整之后发现也还是一样。

悲观锁(没有)

更新语句也以主键作为更新条件,对当行库存数据修改时,锁的颗粒应该是行锁级别(个人见解,不对的话希望指导)

当下单接口请求时,更新库存的sql语句出现了lock_wait的状态。

SELECT * from information_schema.INNODB_TRX;

show processlist;

99fba2861b41123546b296a363a436d3.png

诡异的一点,在对应一直在running的事务,发现了trx_query是为空的,(经人指点之后,说这是事务没有提交也没有回滚时出现的状态)。在 kill 对应的trx_mysql_thread_id 之后,让测试并发的请求该接口,也没有出现事务卡死的情况。但是,==总会隔一段时间就出现==,真是烦人的小妖精。

但后面的我细心地发现,每次出现这个状况时,但是以整点为一个单位地出现,有时候是19:30:05 或者是15:00:03。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值