您当前的位置:首页 > 计算机 > 软件应用 > 数据库 > 其它数据库

真正理解可重复读事务隔离级别

时间:01-26来源:作者:点击数:

事务简介#

SQL 标准定义了四种隔离级别,这四种隔离级别分别是:

读未提交(READ UNCOMMITTED):在这种隔离级别下,可能会出现脏读、不可重复读、幻读问题。

读提交 (READ COMMITTED):解决脏读问题。

可重复读 (REPEATABLE READ):解决脏读、不可重复读问题。

串行化 (SERIALIZABLE):解决脏读、不可重复读、幻读问题。

这里不详细解释脏读、不可重复读、幻读问题这些现象了,介绍事务的文章或书基本都会说得很清楚,但请注意,这些都是事务并发运行时可能产生的现象,而不能理解为数据库的bug!

但我在工作多年后再想到这些知识时,对可重复读行为产生非常大的疑问,如下:

  1. 程序员为什么不把第一次读的数据保留在内存中,第二次重复使用不行吗?为啥要数据库保证两次读出的数据是相同的(即可重复读),并且读两次数据库会浪费更多数据库资源而降低性能。
  2. 另外,每次读出最新的数据有啥不好?读个历史数据有啥用?

既然如此,可重复读到底有什么用?

举个例子#

我们可以考察下面这样的场景,有个金融产品有一个功能,需要查找那些账号余额与账号交易流水对不上的用户,我们叫到账任务吧,而且要在对账任务运行时,用户交易正常不中断。

比如某账号余额100元,该账号有两笔交易记录(+200, -100),这样这个账号就对账正常,但如果程序查询出账号余额100元后,这时用户又转出100元,我们再去查询交易记录时,在不同事务隔离级别下会查到不同的结果,如下:

提交读 可重复读 备注
    开始时余额100,交易记录(+200, -100)
查询到余额100元 查询到余额100元  
    另一事务支出100元,余额减少为0,并提交
查询到交易记录(+200, -100, -100) 查询到交易记录(+200, -100)  
对账失败 对账成功  

可见,在提交读场景下,对账失败了,而可重复读场景下对账成功了,而实际上这个账号的余额与交易记录始终是对齐的。我在MySQL5.7亲自验证,结果确实如此。

所以可重复读具体作用是什么呢?

所以可重复读具体作用是什么呢?

所以可重复读具体作用是什么呢?

它本质作用是保证在开启事务后,对数据库所有表数据的查询,查询到的都是相同的版本,就是开启事务那一刻的版本(在mysql中为第一次查询那一刻的版本),而不管它是查询的一个表,还是不同的表,所以可重复读事务级别解决的并不是表面上的不可重复读现象。

可重复读也经常用在数据库备份过程中,由于数据库备份时数据还有可能在不断修改,我们肯定希望备份整个数据库开始时的那个版本,而不希望备份的数据有些是之前那个时刻版本的,有些则是之后那个时间版本的。

这个例子也说明了另一个问题,即什么时候需要使用事务,刚写代码时我们经常被告知所有写操作要放到一个事务中,实际上,一些特殊场景,多个读操作也要放到一个事务中。

换角度理解事务#

我们可以不从赃读,不可重复读,幻读这些现象看事务隔离级别,而是从读一致性上来理解,如下:

  1. 未提交读,不解决任何读一致性问题,只保证了事务的写一致性(又称原子性),事务提交后,要么都修改成功,要么都不成功。
  2. 提交读,保证其它并发事务的修改要么全可见,要么全不可见,可以理解为"写一致性读",注意断句!"写一致性"、"读",这是最常用的事务隔离级别,可以保证业务数据含义的一致性。
    比如用户下单场景,开事务先后写了order主表订单数据与order_item子表订单中商品数据,如果在两个写中间,有一个未提交读的事务,去读取order与order_item,就会发现只读到了order而没有读到order_item,这给用户看到了,那一定会吓一跳的,我交钱了结果买了一个空单!虽然用户刷新一下又可以看到完整数据。
    但如果使用提交读事务隔离级别就不会有这个问题,用户要么查不到任何数据,要么查到完整数据,这也从侧面说明了逻辑上有关联的数据修改,一定要开事务来操作。
  3. 可重复读,保证事务开启或第一次查询那一刻,后面所有对整个数据库所有表的读都是读那一刻的版本,当然包括重复读同一张表,也可以理解为"一致版本读"。
  4. 串行化,一般来说解决的是并发上的逻辑错误,因为此级别逻辑上可以认为所有事务都是串行执行的(虽然数据库实际上可能会并发执行)。
    比如两个事务先判断数据有没有,没有则插入数据的场景,并发情况下两个事务同时查询,发现没有数据后插入数据,结果插入了两条数据,而使用串行化隔离级别就没有这个问题,这在并发编程中叫竞态条件,所以串行化解决了读写的竞态条件问题。
    当然,这个问题也可以通过添加唯一索引,或使用外部显示加锁的方法来解决。

mysql可重复读是否解决幻读#

在网上,我们经常会看到两种说法的文章,有的说mysql可重复读解决了幻读问题的,也有说没解决的。

这么说也对也不对,具体差异在于当前读取操作是快照读还是当前读,如下:

快照读 当前读 备注
    开始时订单1下有两个order_item,分别A和B
select * from order_item where oid=1(读到A和B) select * from order_item where oid=1(读到A和B) 第一次读
    另一事务在订单1下插入C并提交
select * from order_item where oid=1(读到A和B) select * from order_item where oid=1 for update(读到A、B和C) 第二次读

上面结果同样在mysql5.7下验证通过,我们称其中的select xxx for update为当前读,即读取最新的数据,普通的select则是快照读,在mysql中insert、update、delete、select xxx for update都是当前读。

另外,如果将select xxx for update替换为update order_item set price=199 where oid=1也同样可以更新到3条数据,因为update是当前读嘛,有趣的是后面你再使用普通select也可以查到3条数据,我怀疑是update更改了数据的版本为当前事务的版本,导致快照读也能查到,有深入了解mysql mvcc原理的,也可以告知下理解对不对。

所以,mysql是解决了快照读的幻读问题,没解决当前读的幻读问题,但不管它有没有解决幻读问题,它都是不能替代串行化隔离级别的。

方便获取更多学习、工作、生活信息请关注本站微信公众号城东书院 微信服务号城东书院 微信订阅号
推荐内容
相关内容
栏目更新
栏目热门