在一个@Transactional注解的方法中进行调试，但莫名其妙的就报了下面这个错误：
从内容上看不出个所以然，大概的猜测是事务开启了，一直没有commit，导致MySQL的行被锁住了。下面这个错误证实了我的想法，再次更新同一条数据时，依然失败。
那么，该怎么解决掉这个问题呢？
网上找资料呗。
有几篇文章值得深入的学习和思考：
mysql的锁–行锁，表锁，乐观锁，悲观锁，https://www.cnblogs.com/deliver/p/5730616.html
DRUID连接池的实用 配置详解，https://www.cnblogs.com/wuyun-blog/p/5679073.html
mysql innodb引擎下的行锁获得后 由于意外没有被释放，导致后面的请求无法获得该行锁，怎么办？（由于CSDN的Markdown有些小问题，为了显示得更舒服一点，网址在第四点）
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，现在可以顺利执行了。
果然，有的时候，你要相信，当自己无知的时候，别人说的话永远都是真理。你需要做的就是，去检验它是否真的是真理。
