mysql 隔离价格 死锁_mysql SERIALIZABLE隔离级别死锁问题

本文介绍了在MySQL中使用SERIALIZABLE隔离级别时遇到的死锁问题,通过模拟两个事务并发操作,揭示了由于读写锁竞争导致的死锁现象。在事务A和B中,每个事务先读取再更新同一行,导致双方持有对方需要的锁,从而产生死锁。解决方案包括将`SELECT`改为`SELECT FOR UPDATE`或者在业务层实现事务串行化。
摘要由CSDN通过智能技术生成

最近的项目,为了保障绝对的一致性,使用SERIALIZABLE作为隔离级别。

然后就爆出了很诡异的死锁。

报错log如下:

org.springframework.dao.DeadlockLoserDataAccessException: PreparedStatementCallback; SQL [xxxxx]; Deadlock found when trying to get lock;

try restarting transaction; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

1461 2017-04-17 21:58:26.550 ERROR pool-7-thread-2

我们的sql大概是这样的:

begin;

select * from table_a where id = 6;

INSERT INTO xxx (xxxxx) ON DUPLICATE KEY UPDATE xxxxx;

UPDATE table_a SET column_a = GREATEST(column_a, 0) WHERE id = 6;

commit;

报错的概率并不高,在我们的系统中,大概只有2%的概率左右出现。

单独执行这段sql并不会有任何问题,因此定位了许久。后来灵光一下,同时开启两个事务来模拟这个操作。

方式如下:

//准备工作

1 set session transaction isolat

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值