真正理解可重复读事务隔离级别
原创：打码日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。
事务简介
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中为第一次查询那一刻的版本)，而不管它是查询的一个表，还是不同的表，所以可重复读事务级别解决的并不是表面上的不可重复读现象。
可重复读也经常用在数据库备份过程中，由于数据库备份时数据还有可能在不断修改，我们肯定希望备份整个数据库开始时的那个版本，而不希望备份的数据有些是之前那个时刻版本的，有些则是之后那个时间版本的。
这个例子也说明了另一个问题，即什么时候需要使用事务，刚写代码时我们经常被告知所有写操作要放到一个事务中，实际上，一些特殊场景，多个读操作也要放到一个事务中。
换角度理解事务
我们可以不从赃读，不可重复读，幻读这些现象看事务隔离级别，而是从读一致性上来理解，如下：
未提交读，不解决任何读一致性问题，只保证了事务的写一致性(又称原子性)，事务提交后，要么都修改成功，要么都不成功。 提交读，保证其它并发事务的修改要么全可见，要么全不可见，可以理解为"写一致性读"，注意断句！"写一致性"、"读"，这是最常用的事务隔离级别，可以保证业务数据含义的一致性。
比如用户下单场景，开事务先后写了order主表订单数据与order_item子表订单中商品数据，如果在两个写中间，有一个未提交读的事务，去读取order与order_item，就会发现只读到了order而没有读到order_item，这给用户看到了，那一定会吓一跳的，我交钱了结果买了一个空单！虽然用户刷新一下又可以看到完整数据。
但如果使用提交读事务隔离级别就不会有这个问题，用户要么查不到任何数据，要么查到完整数据，这也从侧面说明了逻辑上有关联的数据修改，一定要开事务来操作。可重复读，保证事务开启或第一次查询那一刻，后面所有对整个数据库所有表的读都是读那一刻的版本，当然包括重复读同一张表，也可以理解为"一致版本读"。 串行化，一般来说解决的是并发上的逻辑错误，因为此级别逻辑上可以认为所有事务都是串行执行的(虽然数据库实际上可能会并发执行)。
比如两个事务先判断数据有没有，没有则插入数据的场景，并发情况下两个事务同时查询，发现没有数据后插入数据，结果插入了两条数据，而使用串行化隔离级别就没有这个问题，这在并发编程中叫竞态条件，所以串行化解决了读写的竞态条件问题。
当然，这个问题也可以通过添加唯一索引，或使用外部显示加锁的方法来解决。
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是解决了快照读的幻读问题，没解决当前读的幻读问题，但不管它有没有解决幻读问题，它都是不能替代串行化隔离级别的。
往期内容
长按关注【打码日记】