mysql原理（十） 当前读与快照读

首先我们做一个模拟，执行以下的sql，其中有如下图数据：

我把执行结果按照表格如下展示：

分析：

在会话1当中，只有当会话1的事务提交后，才能查到最终会话2更改的数据。

在会话2当中，开启事务后更新数据，之后查询发现数据变成了17。

针对上面的现象我们进行个原理分析:

实际上产生上述显现是因为InnoDB采用的MVCC（多版本并发控制），其中针对每条数据会有它自己的事务id，以及一个最大事务id。针对事务中数据每次修改，会产生不同的版本。

1）假设开始id = 2的数据，其事务txid = 1000；

2）当会话1开始，此时txid变成了1001，而会话2开启，txid又变成了1002，同理会话3会变成1003，此时都生成了不同版本的快照。

3）会话1在事务当中去读取时候，采用了快照读的方式，即拿到一个1001的事务id，此时只会读取小于等于自己版本的数据，所以在事务中最终只能拿到值为17的数据。

4）会话2在更新数据的时候，采用的当前读的方式，即对数据增加X锁，获取最新的事务id，读取最新的版本数据。所以在更新之前，就读取到了age的年龄是16，之后在进行+1，得到17.

总结一下：

快照读 解决了幻读的问题，即多次读取数据不一致的问题。

update、insert、delete都会执行 当前读 ，防止并发更新数据导致数据错误，此过程或添加X锁。

快照读 即： snapshot read ，官方叫法是： Consistent Nonlocking Reads ，即： 一致性非锁定读 ，官方的解释是：

即：

即 快照读 的问题在于：在同一个事务中，能够读取到之前提交的数据。表现为：

字面意思：在事务中，为查询创建的快照，并不适用与 DML 语句。

也就是说：如果事务 A 开始时创建的快照，查询不到数据 col1=1 ，但此时事务 B 刚刚提交 insert col1=1 和 insert col1=1 ，此时如果事务 A 执行， delete col1=1 ，是能将事务 B 生成的数据删除的。

字面意思：即使事务 A 的快照是在事务 B 提交之前创建的，但事务 A 也只有在事务 A 和事务 B 都提交后，才能看到事务 B 新增的数据。

建缓冲区。比如其他类型的高速缓存（redis等）作为中间缓冲层。数据的查询，更改首先在这个层处理，处理完再更新到对应的数据库。注意额外增加锁，或者缓存机制防止缓存击穿，雪崩导致系统崩溃。

---