mysql 0x800000000000_Mysql下，批量升级并发操作产生死锁(3)

0:len8;hex80000000000061e5;asca;;

1:len6;hex0000000178ef;ascx;;

2:len7;hex77000002e71b60;ascw`;;

3:len8;hex800000000000b7cf;asc;;

4:len11;hex63726e6870707b383a357d;asccrnhpp{8:5};;

5:len5;hex9992a612fb;asc;;

***WEROLLBACKTRANSACTION(1)

知道了这一天sql会死锁，但是不懂为什么呢？？？

在表上存在字段，并发插入数据的状况下形成死锁，求解

benluobobo04-19 11:06

等级

6楼

程类UpdateNameTask的run()方法，执行下面两步操作：

1)根据id更新name值：updatetestsetname='newname'whereidin(XXX);

这里的XXX表示，根据不同线程获得的id，对于线程t1，就是0,8,16,...，表示id对8取模余数为0的所有记录的id

2)根据字段key更新name值：updatetestsetname='newname2'where`key`in(YYY);

这里的YYY表示，1)中的这些记录对应的key值

将以上两步放在同一个事务中

mysql批量更新update操作，导致锁表

matrix198404-19 11:34

等级

7楼

引用6楼benluobobo的回复:程类UpdateNameTask的run()方法，执行下面两步操作：

1)根据id更新name值：updatetestsetname='newname'whereidin(XXX);

这里的XXX表示，根据不同线程获得的id，对于线程t1，就是0,8,16,...，表示id对8取模余数为0的所有记录的id

2)根据字段key更新name值：updatetestsetname='newname2'where`key`in(YYY);

这里的YYY表示，1)中的这些记录对应的key值

将以上两步放在同一个事务中

我将两步的sql通过addBatch(sql)放在一起，执行，跟你说的在一个事务中执行，是一样的吗？

_stmt = conn.createStatement();

stmt.addBatch(String.format(updateSql, "["+mod+":"+remainder+"]", _ids));

stmt.addBatch(String.format(updateSql2, "{"+mod+":"+remainder+"}", _keys));

stmt.executeBatch();

结果是：所有的线程全部死锁！

16 死锁的造成和解决

matrix198404-19 11:44

等级

8楼

引用7楼matrix1984的回复:Quote: 引用6楼benluobobo的回复:

程类UpdateNameTask的run()方法，执行下面两步操作：

1)根据id更新name值：updatetestsetname='newname'whereidin(XXX);

这里的XXX表示，根据不同线程获得的id，对于线程t1，就是0,8,16,...，表示id对8取模余数为0的所有记录的id

2)根据字段key更新name值：updatetestsetname='newname2'where`key`in(YYY);

这里的YYY表示，1)中的这些记录对应的key值

将以上两步放在同一个事务中

我将两步的sql通过addBatch(sql)放在一起，执行，跟你说的在一个事务中执行，是一样的吗？

_stmt = conn.createStatement();

stmt.addBatch(String.format(updateSql, "["+mod+":"+remainder+"]", _ids));

stmt.addBatch(String.format(updateSql2, "{"+mod+":"+remainder+"}", _keys));

stmt.executeBatch();

结果是：所有的线程全部死锁！

我的意思是多线程死锁的伪代码，之前只是部分死锁(个别没执行失败)，用这种的方法后每个线程的每个sql都没执行失败的。

死锁的造成因素和解除

benluobobo04-19 12:11

等级

9楼

从日志可以很简单的看出

第一个事务在执行updatewherekey的之后终于锁定了spaceid64pageno606nbits304index`PRIMARY`oftable`test`.`test

而这个索引行是第二个事务在执行updatewhereid的之后还要锁定的行

第二个事务在执行的之后终于锁定了spaceid64pageno447nbits400index`PRIMARY`oftable`test`.`test`

而这个索引行正是第一个事务以后还要的

真正的缘由是鉴于id是非唯一索引，在锁定的之后不能做到recordlock，必须将对应的primarykeylock

你可以试着将id改成unqiuekey再试试看

死锁产生原理

matrix198404-19 13:10

等级10楼

本文来自电脑杂谈，转载请注明本文网址：

http://www.pc-fly.com/a/jisuanjixue/article-121335-3.html