mysql - MVCC 行锁定与教科书事务行为

Question

我对交易的理论和实现感到困惑。
根据教科书，数据项有共享锁和排他锁，这些锁是冲突的。因此，如果一个事务具有排他锁(用于插入/更新)，那么即使是读取(选择/共享锁)，其他事务也无法访问该数据项。
到目前为止，这是很清楚的。但这在实际实现中似乎并不适用。
mysql 中的示例:

session1> begin;  
session2> begin;  
session2> insert into table (id, desc) values (1234, 'test');  
session1> select * from table;

执行session 1的select。如果我用 select ...for update
替换它，它只会被阻止 only但我不明白为什么普通选择不会阻塞。它应该获得一个与独占/写锁冲突的共享锁。
这似乎是由于 MVCC，但这是否意味着 MVCC 不遵守有关事务交互的教科书描述？
我看到的 DELETE 而不是 INSERT

的行为相同

Answer 1

MVCC与传统的锁有些不同的是，随便说:

1. 作者不会阻止读者
2. 读者不会屏蔽任何人，也不会被任何人屏蔽。

如果您想要可扩展性，这是一个关键特性，因为它避免了很多争用。它有一个棘手的问题:在某些情况下，MVCC 的行为并不像您直觉上预期的那样。尽管如此，MVCC 还是非常有用，不容忽视，因此您只需了解它的细微差别即可。最典型的一个是您可以使用 SERIALIZABLE 隔离级别并获得最终状态，您无法通过所涉及事务的任何串行执行获得该最终状态。

在您的特定情况下，SELECT 不会因为 1 而阻塞。但是，SELECT ... FOR UPDATE 确实会阻塞，因为它充当“某种”作者，因此它被其他作者阻止。

推荐链接:

• About MVCC
• About ANSI/ISO SERIALIZABLE isolation level
• About serializable transactions and their interaction with MVCC
• About serializability