MySQL MVCC机制---图文并茂带你深入浅出

前言

事务

我们知道，事务具有四大特性（ACID）：

1. 原子性（Atomicity）：令一个事务的所有操作不可分割，要么全部执行、要么全不执行。
2. 隔离性（Isolation）：事务并行处理时，不同的事务之间操作数据不相互影响。
3. 一致性（Consistency）：事务满足现实世界的约束，保持正确的状态。
4. 持久性（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查询到了一个数据，过一