阅读 1599

关于innodb下,幻读是如何被解决的

innodb下幻读是如何在RR级别下被解决的?

先来简单的复习一下数据库隔离级别

  1. RU(Read Uncommitted)

一个事务A读取到另一个事务B未提交的修改,B回滚了,就造成了数据不一致。(现象:脏读)

  1. RC(Read Committed)

一个事务A在事务执行过程中第一次读取的值和第二次读取的值不一致,这是由于事务B在俩次读取之间修改了数据并提交了事务。(现象:不可重复读)

  1. RR(Repeatable Read)

一个事务A在事务执行过程中第一次读取的值和第二次读取的值一致(解决了不可重复读),但是其他事务B 的insert 或者 delete的操作,会影响到俩次查询的条数(现象:幻读)

  1. Serializable

最高的事务隔离级别,串行化。


问题来了:RR下会出现幻读,那为什么innodb能在RR下解决幻读呢?不是互相矛盾吗?

解释:这是由于innodb和标准不一致导致的。具体可以看看github火热的讨论Innodb RR 下能否防止幻读?

结论:RR 下,innodb下的幻读是由MVCC 或者 GAP 锁 或者是next-key lock 解决的。

关于MVCC 可以查看这篇文章 MVCC原理

意思就是MVCC判断了记录的可见性,比如 select count(*) from table where col_name = xxx 时(属于快照读),在RR 级别下,这条事务在事务一开始就生成了readview,通过这个readview 这条语句将会找到符合条件的行并且计算数量。 那么关于与如何找到这些符合条件的行,满足where 条件的同时也得满足本事务对这些行的可见性。 所以在同一事务里并不会产生幻读的现象。

关于GAP 锁 可以查看这篇文章next-key lock

在这里我们需要了解 当前读快照读 的区别

  1. 快照读:简单的select操作,属于快照读,不加锁。 select * from table where ?;

  2. 当前读:特殊的读操作,插入/更新/删除操作,属于当前读,需要加锁。
    select * from table where ? lock in share mode;
    select * from table where ? for update;
    insert into table values (…);
    update table set ? where ?;
    delete from table where ?;

    所有以上的语句,都属于当前读,读取记录的最新版本。并且,读取之后,还需要保证其他并发事务不能修改当前记录,对读取记录加锁。其中,除了第一条语句,对读取记录加S锁 (共享锁)外,其他的操作,都加的是X锁 (排它锁)。

我们来以下倆段伪代码:

//code 1
beginTransaction

delete * from table where id = ?  (加了二级索引(不是唯一索引))

endTransaction


//code 2
beginTransaction

select count(*) from table where id = ? for update (加了二级索引(不是唯一索引))

endTransaction

复制代码
  1. code 1 的分析:
    由于delete * from table where id = ? 这是当前读,它会锁定一个范围采用GAP 锁的方式,让符合条件的范围内不得让其他事务插入数据,这样也就解决了幻读。
  2. code 2 的分析:
    由于select count(*) from table where id = ? for update 虽然也是当前读,但是它加的锁是next-key-lock,它是由GAP锁和record锁组成的,所以它也能锁定范围不让其它事务插入符合条件的数据,锁定记录本身,也不让其它事务修改数据。这样也就避免了幻读。