MySQL UPDATE 锁会因为连续的 SHARE 锁而饿死吗

发布于05月05日

我有两个不同的事务，其中一个对SELECT条语句使用读锁(FOR SHARE)，另一个使用写锁(FOR UPDATE).

假设他们正试图获得同一排的锁.以下是我试图理解的情景.

假设我有连续的请求流使用读锁，有时我需要获取写锁.

这些锁是使用FIFO策略来避免饥饿，还是其他一些策略，比如读锁，只要它能够获取锁，写锁就会等待所有读操作耗尽(在这种情况下，甚至是新的读操作).

我怀疑可能会发生第二次，但我不是100%确定.

我正在调查一个问题，找不到关于这个问题的好文档.

推荐答案

如果您缺乏文档，可以try 以下实验:

窗口1:

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from tablename for share;
+---------------------+
| ldt                 |
+---------------------+
| 1969-12-31 16:00:00 |
+---------------------+
1 row in set (0.00 sec)

窗口2:

mysql> update tablename set ldt=now();
(hangs, waiting for lock)

窗口3:

mysql> select * from tablename for share;
(hangs, also waiting for lock)

这表示X锁请求正在阻止后续的S锁请求.

50秒过go 了，然后:

窗口2:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

然后马上:

窗口3:

mysql> select * from tablename for share;
+---------------------+
| ldt                 |
+---------------------+
| 1969-12-31 16:00:00 |
+---------------------+
1 row in set (41.14 sec)

在等待窗口2中的更新时，窗口3中的 Select 被阻止.当更新超时时，窗口3中的 Select 可以继续.