在InnoDB中,Repeatable Read(重复读)隔离级别通过间隙锁和MVCC机制解决了大部分的幻读问题,但并非所有幻读都能被解决。要彻底解决幻读,需要使用Serializable(可串行化)隔离级别。
在Repeatable Read隔离级别下,通过间隙锁解决了部分当前读导致的幻读问题。通过添加间隙锁来锁定记录之间的间隙,以防止新数据的插入。
在Repeatable Read隔离级别下,通过MVCC机制解决了快照读导致的幻读问题。在该隔离级别下,进行快照读时仅在第一次进行数据查询,随后直接读取快照,因此不会发生幻读。
然而,若两个事务操作如下:事务1首先进行快照读,然后事务2插入一条记录并提交,在事务1之后通过更新操作这个新插入的记录,这样可以成功更新,这就是幻读的一种情况。
另外一个场景是,若两个事务的顺序为:事务1先进行快照读,接着事务2插入了一条记录并提交,在事务1进行当前读后,再次进行快照读也会导致幻读的发生。
MVCC解决幻读
MVCC,即多版本并发控制(Multiversion Concurrency Control),类似于数据库锁,是一种并发控制的解决方案。它主要用于解决读-写并发的情况。
我们了解,在MVCC中存在两种读取方式:快照读和当前读。
快照读指的是读取快照数据,即在生成快照的那一瞬间的数据。例如,通常情况下我们使用的普通SELECT语句在不加锁的情况下就是一种快照读。
在可重复读(RC)中,每次读取都会重新生成一个快照,始终读取行的最新版本。在可重复读(RR)中,快照会在事务第一次执行SELECT语句时生成,只有在本事务中对数据进行更改才会更新快照。
因此,在RR隔离级别下,同一事务中的多次查询不会检索到其他事务的更改内容,因此能够解决幻读问题。
若我们将事务隔离级别设置为RR,由于MVCC的机制,就可以解决幻读问题。
有这样一张表:
CREATE TABLE users (
id INT UNSIGNED AUTO_INCREMENT,
gmt_create DATETIME NOT NULL,
age INT NOT NULL,
name VARCHAR(16) NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB;
INSERT INTO users(gmt_create,age,name) values(now(),18,'Paidaxing');
INSERT INTO users(gmt_create,age,name) values(now(),28,'Paidaxing2023');
INSERT INTO users(gmt_create,age,name) values(now(),38,'Paidaxing666');
执行如下事务时序:
事务1 |
|
SET session TRANSACTION ISOLATION LEVEL REPEATABLE READ; |
|
BEGIN; |
|
SELECT * FROM users WHERE AGE > 10 AND AGE 10 AND AGE < 30; |
可以观察到,在同一个事务中,两次查询的结果是相同的。在可重复读(RR)级别下,由于采用了快照读,第二次查询实际上是读取的快照数据。
间隙锁与幻读
我们已经讨论了MVCC如何解决了可重复读(RR)级别下的快照读造成的幻读问题,那么在当前读取(READ COMMITTED)下,如何解决幻读问题呢?
当前读取即读取最新数据,因此,锁定的SELECT语句,或者进行数据的插入、删除、更新都属于当前读取操作,例如:
SELECT * FROM xx_table LOCK IN SHARE MODE;
SELECT * FROM xx_table FOR UPDATE;
INSERT INTO xx_table ...
DELETE FROM xx_table ...
UPDATE xx_table ...
举一个下面的例子:
事务1 |
事务2 |
SET session TRANSACTION ISOLATION LEVEL REPEATABLE READ; |
|
BEGIN; |
|
SELECT * FROM users WHERE AGE > 10 AND AGE < 30 for update; |
|
BEGIN; |
|
INSERT INTO users(gmt_create, age, name) values(now(), 20, 'Paidaxing999'); |
|
阻塞 |
在可重复读(RR)级别下,当我们使用SELECT … FOR UPDATE时,会进行锁定操作。这不仅会对行记录进行加锁,还会对记录之间的间隙进行加锁,这就是所谓的间隙锁。
由于记录之间的间隙被锁定,事务2的插入操作被阻塞,直到事务1释放锁才得以成功执行。
由于事务2无法成功插入数据,因此幻读现象得以避免。因此,在可重复读(RR)级别中,通过引入间隙锁的方式,成功规避了幻读现象的发生。
解决不了的幻读
前面我们讨论了快照读(无锁查询)和当前读(有锁查询)是如何解决幻读问题的。然而,上面提到的例子并非幻读的全部情况。
我们知道MVCC只能解决快照读导致的幻读问题,那么如果一个事务中发生了当前读,在另一个事务插入数据前未加间隙锁,会发生什么呢?
接下来,我们稍作修改上面的SQL代码,采用当前读方式来查询数据:
事务1 |
事务2 |
SET session TRANSACTION ISOLATION LEVEL REPEATABLE READ; |
|
BEGIN; |
|
SELECT * FROM users WHERE AGE > 10 AND AGE 10 AND AGE < 30; |
|
SELECT * FROM users WHERE AGE > 10 AND AGE < 30 for update; |
在上面的例子中,在事务1中,我们并未在事务刚启动时立即加锁,而是进行了一次普通的查询,随后事务2成功插入数据后,事务1再进行了两次查询。
我们观察到,事务1后两次查询的结果完全不同。在没有加锁的情况下,即快照读时,读取的数据与第一次查询结果相同,从而避免了幻读现象。但第二次查询执行了锁定操作,即当前读,因此读取到的数据中包含了其他事务提交的数据,导致了幻读的发生。
倘若您理解了上述例子以及当前读的概念,您将很容易意识到,下面的这个案例事实上也会导致幻读的发生:
事务1 |
事务2 |
SET session TRANSACTION ISOLATION LEVEL REPEATABLE READ; |
|
BEGIN; |
|
SELECT * FROM users WHERE AGE > 10 AND AGE 10 AND AGE 10 AND AGE |