请教一个MYSQL中死锁的问题

Question

我之前对死锁的理解一般情况就是A事务锁定了行a，B事务锁定了行b，然后这时A事务请求行b的锁，B事务请求行a的锁，就会HANG住不动，这就产生了死锁。
最近刚刚接触MYSQL，今天在看文档的过程中看到文档中举得一个死锁的例子，如下
下列的例子演示当锁定请求可能会导致死锁之时一个错误会如何发生。例子中包括两个客户端A和B。首先客户端A创建一个包含一个行的表，然后开始一个事务。在这个事务内，A通过在共享模式选择行获得对行的S 锁定：mysql> CREATE TABLE t (i INT) ENGINE = InnoDB;Query OK, 0 rows affected (1.07 sec) mysql> INSERT INTO t (i) VALUES(1);Query OK, 1 row affected (0.09 sec) mysql> START TRANSACTION;Query OK, 0 rows affected (0.00 sec) mysql> SELECT * FROM t WHERE i = 1 LOCK IN SHARE MODE;+------+| i    |+------+|    1 |+------+1 row in set (0.10 sec)接着，客户端B开始一个事务并尝试从该表删除行：mysql> START TRANSACTION;Query OK, 0 rows affected (0.00 sec) mysql> DELETE FROM t WHERE i = 1;删除操作要求一个X 锁定。因为这个锁定不兼容客户端A持有的S锁定，所以X 锁定不被允许，所以请求进入对行及客户端阻挡的锁定请求队列。最后，客户端A也试图从表中删除该行：mysql> DELETE FROM t WHERE i = 1;ERROR 1213 (40001): Deadlock found when trying to get lock;try restarting transaction客户端A首先对i=1那一行获取了S锁，然后客户端B在delete的时候尝试获取X锁就会进入等待，直到这一步我还是能理解的。可是后来在客户端A尝试删除i=1的数据行的时候，却报发生了死锁的错误，这是为什么呢？

Answer 1

lock in share mode称为共享锁for update称为排他锁
当事务中包含select ...lock in share mode的时候，相关记录将会被锁住，不允许进行修改。这个语句限制在事务表的其他连接上进行UPDATE或者DELETE操作。
这个UPDATE会一直等待A连接执行commit或者rollback才会生效。

Answer 2

事务A获得了这个共享锁，自己也不能修改吗？
我觉得获得了这个锁是可以防止事务B的修改，可我不明白为什么事务A自己修改的时候会报错发现死锁

Answer 3

”因为客户端A需要一个X 锁定来删除该行，所以在这里发生死锁。尽管如此，锁定请求不被允许，因为客户端B已经有一个对X锁定的请求并且它正等待客户端A释放S锁定。因为客户端B之前对X 锁定的请求，被客户端A持有的S锁定也不能升级到X锁定。因此，InnoDB对客户端A产生一个错误，并且释放它的锁定。在那一点上，客户端B的锁定请求可以被许可，并且客户端B从表中删除行。 “这是文档里关于上面这段代码解释的一段话
如果非要理解，我只能这么理解：
1、就是说事务B优先进入了等待X锁的队列，而事务A排在它后面，因此只要B获取不了X锁，A肯定获取不到
2、A锁持有S锁，因此B也不可能获得X锁这样就发生死锁了

Answer 4

1. B 等待A释放共享锁
2. A 的delete等待B释放排他锁

Answer 5

可是B并没有获得排他锁啊，因为B也在等待A的共享锁释放以后他才能获得排他锁所以我更倾向于我前面说的那种解释，A和B都在等待排他锁，只不过B排在A前面个人观点，欢迎讨论

Answer 6

A连接没有执行commit或者rollback，一直是锁定状态

Answer 7

看下英文的文档感觉更明朗些了
Deadlock occurs here because client A needs an X lock to delete the row. However, that lock request cannot be granted because client B already has a request for an X lock and is waiting for client A to release its S lock. Nor can the S lock held by A be upgraded to an X lock because of the prior request by B for an X lock. As a result, InnoDB generates an error for client A and releases its locks. At that point, the lock request for client B can be granted and B deletes the row from the table.