首先我们做一个模拟,执行以下的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 新增的数据。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)