mysql innodb引擎下的行锁由于意外没有被释放,导致后面的请求无法继续,怎么办?-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

mysql innodb引擎下的行锁由于意外没有被释放,导致后面的请求无法继续,怎么办?

简介: 版权声明:欢迎转载,请注明沉默王二原创。 https://blog.csdn.net/qing_gee/article/details/80108576 在一个@Transactional注解的方法中进行调试,但莫名其妙的就报了下面这个错误: 从内容上看不出个所以然,大概的猜测是事务开启了,一直没有commit,导致MySQL的行被锁住了。
版权声明:欢迎转载,请注明沉默王二原创。 https://blog.csdn.net/qing_gee/article/details/80108576

在一个@Transactional注解的方法中进行调试,但莫名其妙的就报了下面这个错误:

这里写图片描述

从内容上看不出个所以然,大概的猜测是事务开启了,一直没有commit,导致MySQL的行被锁住了。下面这个错误证实了我的想法,再次更新同一条数据时,依然失败。

这里写图片描述

那么,该怎么解决掉这个问题呢?

网上找资料呗。

有几篇文章值得深入的学习和思考:

  1. mysql的锁–行锁,表锁,乐观锁,悲观锁,https://www.cnblogs.com/deliver/p/5730616.html
  2. DRUID连接池的实用 配置详解,https://www.cnblogs.com/wuyun-blog/p/5679073.html
  3. mysql innodb引擎下的行锁获得后 由于意外没有被释放,导致后面的请求无法获得该行锁,怎么办?(由于CSDN的Markdown有些小问题,为了显示得更舒服一点,网址在第四点)
  4. https://www.zhihu.com/question/56380924/answer/149316845

首先,我的数据库链接使用的是阿里的Druid,所以第二篇文章中读到以下关键信息:

testOnBorrow |true| 申请连接时执行validationQuery检测连接是否有效,做了这个配置会降低性能。

而我项目中的该值设置为false。瞬间感觉问题就要马上解决了,但不了解事情的真相就想要解决问题,是不可能的。果然,把数据库链接配置中testOnBorrow 设置为true,于事无补。

那么,第三篇文章对我应该是有帮助的。毕竟我先要把锁释放掉,因为我还有一大顿的测试要做。从第三篇文章中我找到以下关键信息:

其次,如果真的出现了这样的问题,那就通过命令show engine innodb status\G,找到ACTIVE时间长的(需要通过其中信息确定一下是不是这个事务,最好别找错了),通过这些信息找到对应的thread id,然后kill connection threadid,将其杀掉,恢复业务正常运行,然后再去改业务代码上存在的问题吧。

这位朋友提供的方法我认为是正解,于是使用Navicat进入数据库的命令行界面,执行:
show engine innodb status\G
结果令人失望:

mysql> show engine innodb status\G;
1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘\G’ at line 1
mysql>

该怎么办呢?

网上找资料呗。

有朋友提供这样的信息,说这条语句只能在mysql的cmd或者shell界面下执行,我很怀疑这句话的正确性。但事实证明我是多么的无知,他说的是对的,我的怀疑是多余的。

这里写图片描述

为什么?为什么真理永远被别人掌握?为什么我就偏偏不知道呢?

对于技术能力在我之上的,能解决我问题的人,我感到由衷的佩服,请收下我的膝盖。

嗯,不过,等一等,这条语句show engine innodb status\G;执行后的结果都什么玩意啊?我表示看不懂,难道不看了吗?

当然不行,要解决问题啊,耐着头皮继续看呗。

这里写图片描述

嗯,发现了“金银岛”,这不就是“ACTIVE时间长的”?懂行的人的话语永远都那么少,那么精辟,那么直达人心。其中thread id为“221489”,还等什么,立马kill掉它。

mysql> kill connection  221489;
Query OK, 0 rows affected (0.00 sec)

mysql>

我就好像是出门大张的小兵,出门之前元帅告诉我要这么这么这么这么做,嗯,我点点头,表示对他的话一知半解。到底对不对?有待检验。

[SQL]UPDATE mem_point SET `shop_offset` = 0 WHERE uid=35;
受影响的行: 1
时间: 0.000s

嗯,没错,老板说得千真万确,之前一直被锁的update,现在可以顺利执行了。
果然,有的时候,你要相信,当自己无知的时候,别人说的话永远都是真理。你需要做的就是,去检验它是否真的是真理。


我就是这一个人,永远都在进步。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章