浅析MySQL的事务隔离之一致性读

知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个数据库开发实战，手把手教大家学习《浅析MySQL的事务隔离之一致性读》，在实现功能的过程中也带大家重新温习相关知识点，温故而知新，回头看看说不定又有不一样的感悟！

前言

之前简单的了解了MySQL的事务隔离级别，我们知道，MySQL中最常用的事务隔离级别有可重复读（RR）和读提交（RC）。
其中，RR级别下，数据在事务启动时到事务提交后的读取是一致的，本篇文章我们来仔细剖析一下一致性读到底是怎么实现的，以及某些情况下不一致的问题。

快照（一致性视图）

在RR隔离级别下，当事务启动时，会创建一个整库数据快照（一致性视图）供当前事务操作，每个事务都有自己的快照（一致性视图），这样就保证了数据的隔离性，事务之间的操作不会相互影响。
需要注意的是，快照（一致性视图）并不是整库的数据copy，而是基于事务id（transaction_id）和行记录id（row trx_id）来实现的。在InnoDB中，每一个新的事务都会有一个唯一的递增事务id，每一行会有多个修改记录id，当前事务对该行操作时，会将transaction_id赋给当前行的trx_id，且旧版本的trx_id还需要保存，以供事务查询该行数据时使用。

多版本

InnoDB中，保证多版本是通过回滚日志来实现的（undolog），回滚日志（undolog）就是上图的U1，U2，U3。上图中最新操作的结果为V4，要想得到V1的值，就根据V4的值和undolog一步一步往前计算得到。也就是说，V1，V2，V3的数据不是物理存在的，是根据日志往前推出的。

当前读

在RR下，数据隔离机制为：
1、未提交的不可见；
2、当前事务快照创建前，已提交的可见
3、当前事务快照创建后，已提交的不可见

假设上图中k的初始值为1。
根据以上内容，图中A，B分别select到什么内容呢？（事务C更新完即提交了事务，所以事务B是不会阻塞的）
事务A先创建了快照，事务B随后创建快照，然后执行了事务C。
对于A：A获取数据不受B，C影响，是1
对于B：B执行update时，为了不影响已提交事务对该行的更新操作，会先读再修改，而这个读是当前读，读到的是最新的数据。（根据 row trx_id），然后更新当前行的最新版本，之后B再去select，就读到了经过C和B都更新后的最终数据3

在更新数据时，都是先读后写的，而这个读是当前读，只读当前最新的已提交事务的值。不仅update能当前读，当

select ... lock in share mode或select ... for update

时也可以当前读

可重复读和读提交

可重复读的核心就是一致性读；事务更新时，用的是当前读；但是当某行数据被未提交的事务update加行锁时，其他事务只能等待事务提交锁释放才能继续操作。
在可重复读中，在事务开始时建立数据快照（一致性视图），该事务的其他操作共用一个快照（一致性视图）。
在读提交隔离下，数据快照（一致性视图）在每一个语句执行前都会重新计算，所以，只要事务启动后，select前，其他事务提交了数据更新，那么select都能查询到已提交的最新数据。

总结

在InnoDB中，每行数据都有自己的row trx_id版本，每个事务或语句都有自己的数据快照（一致性视图），在普通查询下，根据版本id获取数据快照中可见的数据。
所以对于可重复读，查询只承认在事务启动前就已提交完成的数据。
对于读提交，查询只承认在语句执行前就已提交完成的数据。

理论要掌握，实操不能落！以上关于《浅析MySQL的事务隔离之一致性读》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！