MySQL 两个死锁样例

【引子】

　　从事MySQL-DBA这一行也有些年头了，想对新人说，在分析死锁问题时应该还要考虑到有一个叫请求队列的“概念”。之所以

　　在这里提这个不是因为新手不知道，而是有时候会自然而然的想不到。

 

　　不信的话，我下面要说的这个例子每个dba都知道要排队

　　session A

creat table t(x int primary key);
insert into t(x) values(1);

start transaction;
update t set x=2 where x=1; 

　　session B

update t set x=3 where x=1;

　　由于session A持有着x=1那一行的“X”锁，所以当session B要去更新x=1这一行时它就只能是等待了，此时如果有session C它也要去更新

　　x=1的行，那么session C的获取锁的请求就要排在session B的后面。

 

 

【样例一】

　　session A

create table t(id int primary key);

insert into t(id) values(1);

start transaction;

select * from t where id=1 for share;
+----+
| id |
+----+
|  1 |
+----+
1 row in set (0.00 sec)

　　session B

update t set id=1 where id=1;

　　session C

update t set id=1 where id=1;

由于session A已经持有id=1这一行记录的“S”锁，所以session B 和session C都要等待，还要知道另一件事就是session B的等待请求排在session C

前面，也就是说要想session C能得到锁，它要等session B用完了之后才能拿到，然而session B要等session A用完之后它才可能拿到。

 

有没有想到一个问题，如果这个上时候session A再去请求id=1这一行上的“X”锁，然而这把锁永远都不可能得到了，原因是session A的“X”锁请求

排在了session C的后面，seesion C要能得到锁的关键是session 释放“S”让session B得以进行；但是session A还没有到释放“S”锁的阶段

所以死锁就产生了。

 

看下面的操作

　　session A

update t set id=1 where id=1;
Query OK, 0 rows affected (0.01 sec)
Rows matched: 1  Changed: 0  Warnings: 0

　　session B

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

　　session C

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

 

可以看到为了解除死锁mysql 把session B 和session C 给干掉了

 

 

 

未完 ... ...

 

 

 

----