MySQL MVCC机制---图文并茂带你深入浅出
已于 2022-01-29 15:29:29 修改·890 阅读
1
6·
本文探讨了事务隔离性的概念，详细解析了脏读、脏写、不可重复读和幻读，以及如何通过MVCC机制和InnoDB的隔离级别、版本链来平衡事务安全与性能。通过实例和理论相结合，揭示了InnoDB在读写并发中的执行机制。文章目录
前言
事务
我们知道，事务具有四大特性（ACID）：
- 原子性（
Atomicity）：令一个事务的所有操作不可分割，要么全部执行、要么全不执行。 - 隔离性（
Isolation）：事务并行处理时，不同的事务之间操作数据不相互影响。 - 一致性（
Consistency）：事务满足现实世界的约束，保持正确的状态。 - 持久性（
Durability）：事务一旦提交，对数据的修改就是永久性的，即使数据库出现故障也不会让修改丢失。
隔离性
本文我们深入探究下事务的隔离性，首先通过一个例子看看并行条件下不同事务是如何相互影响的：
案例：数据A值为5，创建两个事务，共同对数据A减1，在串行处理条件下两个事务提交后A的结果应该为3。
对A减一需要分三步操作：读取变量A，将变量A减一，将变量A写回主存，两个事务并行处理可能的结果如下表所示：
由上表可知最终得到的结果是A=4，显然这是由于事务之间读取变量时相互影响造成的，所以为了保证并行处理的一致性要求，我们应该让事务之间按照顺序一个一个单独执行，或者最终执行的效果和单独执行一样，最终结果就是事务之间没有影响，看起来像是被互相隔离了一样，这也就是事务的隔离性。
一、如何保证事务的隔离性？
我们能想到的最简单的一种方式就是加锁，即在当前事务执行的过程中，其他事务阻塞，排队等待当前事务执行完毕提交，数据每次只能被一个事务所读写。这种多个事务的执行方式称之为可串行化执行。
通过可串行化执行，我们可以确保事务的一致性是一定被保证了的，无论是读-写、写-读、还是写-写情况，事务之间都是完全隔离，没有任何影响的。
但是这种执行方式对性能影响太大，尤其是在多核CPU条件下，硬件的优势丝毫没有得到发挥。那么我们能不能微微减弱可串行化执行的隔离性呢？也就是说，可以让事务之间没有那么彻底地隔离，做到兼顾性能与安全。
在研究之前，我们首先应该详细地先了解事务之间是怎么互相影响的，都有哪些影响方式影响了事务的一致性。
二、事务之间相互影响的探究
假设存在两个事务在并发条件且没有任何隔离措施情况下执行任务，两个线程分别为事务A，事务B。事务A的功能是修改数据，事务B的功能是读取数据。
1.脏写
现象：
事务B写了一个数据，过一会发现没写上。
本质原因：
事务A修改了某一数据的值，随后事务B也修改了这个数据并提交了，但是A还没有提交，所以A随时都有回滚的可能，假设A在某一时刻回滚，任务回到了最初的起点（即A修改前的状态），所以就导致了已经提交了的事务B没写上该数据。
2.脏读
现象：
事务B查询到了一个数据，过一
最低0.47元/天 解锁文章
扫一扫
4 条评论
hengbo.liu2024.07.17你好，这个为啥是可见的啊，默认可重复读隔离级别，不是只能看到，活跃的最小事务ID之前提交的事务吗，在已经创建读视图的情况下，其他事务进行提交的事务，也可以看到吗？min_trx_id < trx_id < max_trx_id，则需要判断trx_id是否在m_ids列表中，即判断该版本的事务是否提交，若未提交则不可被访问，若提交则可以被访问
Dancing With Bugs回复hengbo.liu2024.07.17你理解的没问题，创建视图后看不到后提交的事务，原文想表达的意思是当前版本是否为生成一致性视图时的活跃事务所生成的，是的话就不可见。
14642233
到【灌水乐园】发言
