本篇内容介绍了“Mysql事务死锁触发Rollback异常的排查过程”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！整个事件起源于一个Error，日志如下：日志说的很明白，更新某行数据时发现死锁，并抛了个MySQLTr 香港云主机ansactionRollbackException异常。那么问题来了，为什么死锁了？Mysql InnoDB 提供了死锁检测机制，通过Wait-For-Graph算法实现。简单讲就是将事务及它等待的锁维护成一个有向图，然后进行环检测，如果发现有环则表示发生了死锁，InnoDB需要回滚掉一个事务以打破环，因此抛出了上面的异常。所以，对于日志上的update，肯定有另一个事务和这个update所在的事务有相互的锁等待。为了找到另外一个事务，可以在数据库执行show engine innodb status查询最近的一次死锁情况，日志如下：可以看到，事务1(xid 872050326)等待pop_sku_relation的一个X锁:RECORD LOCKS space id 5155 page no 23 n bits 144 index PRIMARY of table jolly_pop_center.pop_sku_relation trx id 872050326 lock_mode X locks rec but not gap waiting Record lock事务2(xid 872050288)持有pop_sku_relation的一个X锁（注意是一行记录）:RECORD LOCKS space id 5155 page no 23 n bits 144 index PRIMARY of table jolly_pop_center.pop_sku_relation trx id 872050288 lock_mode X locks rec but not gap Record lock然后事务2(xid 872050288)还等待pop_goods的一个X锁：RECORD LOCKS space id 11311 page no 66 n bits 96 index PRIMARY of table jolly_pop_center.pop_goods trx id 872050288 lock_mode X locks rec but not gap waiting Record lock然后事务2(xid 872050288)被回滚了：*** WE ROLL BACK TRANSACTION (2)这里可以让DBA帮忙捞事务1(xid 872050326)的binlog， 因为事务2回滚后，死锁解除，事务1执行成功则会记录binlog日志。应该能发现事务1也对pop_goods的同一行进行了操作。最后跟踪代码，果然发现有一个事务首先更新了pop_goods，然后再更新pop_sku_relation。另一个事务中先更新了pop_sku_relation,然后更新pop_goods。在并发的情况下就会发生上面日志的情况：事务1对pop_goods中id=1253的记录上X锁事务2对pop_sku_relation中id=14616485的记录上X锁事务1申请pop_sku_realtion中id=14616485的记录的X锁，因为事务2已经锁了所以等待事务2申请pop_goods中id=1253的记录的X锁，因为事务1已经锁了所以等待发现事务1和事务2相互等待，回滚事务2最后修改代码，使update顺序保持一致。 本例中是对不同表的修改不一致，其实对同一张表不同记录如果两个事务乱序，也会产生死锁现象。因此如果有多记录更新的时候，不同表需要固定一个更新顺序，同一张表的不同记录需要进行排序再更新，从而避免死锁的发生。“Mysql事务死锁触发Rollback异常的排查过程”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注开发云网站，小编将为大家输出更多高质量的实用文章！
Java中怎么对InputStream进行操作，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。1、in.available()该方法不能保证所有的流已到达2、二进制流读取错误方式3、…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
