SQL 标准定义了四种隔离级别,这四种隔离级别分别是:
读未提交(READ UNCOMMITTED):在这种隔离级别下,可能会出现脏读、不可重复读、幻读问题。
读提交 (READ COMMITTED):解决脏读问题。
可重复读 (REPEATABLE READ):解决脏读、不可重复读问题。
串行化 (SERIALIZABLE):解决脏读、不可重复读、幻读问题。
这里不详细解释脏读、不可重复读、幻读问题这些现象了,介绍事务的文章或书基本都会说得很清楚,但请注意,这些都是事务并发运行时可能产生的现象,而不能理解为数据库的bug!
但我在工作多年后再想到这些知识时,对可重复读行为产生非常大的疑问,如下:
既然如此,可重复读到底有什么用?
我们可以考察下面这样的场景,有个金融产品有一个功能,需要查找那些账号余额与账号交易流水对不上的用户,我们叫到账任务吧,而且要在对账任务运行时,用户交易正常不中断。
比如某账号余额100元,该账号有两笔交易记录(+200, -100),这样这个账号就对账正常,但如果程序查询出账号余额100元后,这时用户又转出100元,我们再去查询交易记录时,在不同事务隔离级别下会查到不同的结果,如下:
提交读 | 可重复读 | 备注 |
---|---|---|
开始时余额100,交易记录(+200, -100) | ||
查询到余额100元 | 查询到余额100元 | |
另一事务支出100元,余额减少为0,并提交 | ||
查询到交易记录(+200, -100, -100) | 查询到交易记录(+200, -100) | |
对账失败 | 对账成功 |
可见,在提交读场景下,对账失败了,而可重复读场景下对账成功了,而实际上这个账号的余额与交易记录始终是对齐的。我在MySQL5.7亲自验证,结果确实如此。
所以可重复读具体作用是什么呢?
所以可重复读具体作用是什么呢?
所以可重复读具体作用是什么呢?
它本质作用是保证在开启事务后,对数据库所有表数据的查询,查询到的都是相同的版本,就是开启事务那一刻的版本(在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是解决了快照读的幻读问题,没解决当前读的幻读问题,但不管它有没有解决幻读问题,它都是不能替代串行化隔离级别的。