我修改下答案,之前说的update的读会先加S锁再升级成X锁这个说法是不正确的,这个回答是我之前在一位大V的博客中看到的,而没有自己去求证验证误导大家,不好意思,我特意看了下mysql的官方文档,并且经过验证,MySQL的update语句在读的时候就直接加的X锁,会阻塞其它的DML语句的读(insert, update, delete等),所以不会发生死锁,我的验证思路是:
create table tt(a int, b int, primary key(a)) engine=innodb;
insert into tt values(1, 1);
然后开启一个显示事务t1
begin;
update tt set b=1 where a=1;
先不提交
再开一个session2,也开启一个事务t2:
begin;
update tt set b=1 where a=1;
虽然t1并没有发生实际的更新,但是t2的事务会一直等在行锁上,被阻塞住,commit t1后t2可以继续执行,由此可见,update的读是加的X锁,所以不会发生死锁
这个地方感觉SQL Server做得更好,SQL Server的update语句在读的时候会加U锁,U锁是一种介于S锁和X锁之间的锁,而且只有U锁可以升级成X锁,当一行上有S锁,可以加U锁,当一行上有U锁,不能再继续加X锁或者U锁,但是可以加S锁,当持有U锁的行需要被更新的时候会升级成X锁,这样就保证了只有一个人能持有可变更的锁,避免了死锁,而同时又没有因为直接上X锁而阻塞太广。