事务的隔离性

事务的概念

简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。但不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。
事务有四大特性，即我们常说的ACID，即Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性）。

1. 原子性：一个事务中的sql语句要么都成功，要么都失败，如果其中一个执行失败则已执行成功的语句都会回滚至修改之前的状态
2. 一致性：数据库处理前后结果应与其所抽象的客观世界中真实状况保持一致。这种一致性是一种需要管理员去定义的规则。管理员如何指定规则，数据库就严格按照这种规则去处理数据。比如这个例子：如果说AB账户总金额5000就是数据库的一致性规则，那么我能不能把A账户转走10000给B，让B账户有10000，而A剩下-5000？从数学上来看完全正确，但这显然是不符合常理的。而这种常理，就是所谓的一致性。
3. 隔离性：并发执行的不同事务间内部的操作是互不影响的
4. 持久性：一个事务一旦提交成功，那么它对数据库的改变就是永久性的

事务的隔离性

我们重点聊一下事务的隔离性。当数据库上有多个事务同时执行的时候，就可能出现脏读，不可重复读，幻读的问题，为了解决这些问题，就有了隔离级别的概念。
我们要注意，你隔离的越严实，效率就会越低。
我们来看看SQL标准的事务隔离级别的分类：

1. 读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。
2. 读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。
3. 可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
4. 串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个SQL语句开始执行的时候创建的。这里需要注意的是，“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问

注意：Oracle数据库的默认隔离级别其实就是“读提交”，因此对于一些从Oracle迁移到MySQL的应用，为保证数据库隔离级别的一致，你一定要记得将MySQL的隔离级别设置为“读提交”。配置的方式是，将启动参数transaction-isolation的值设置成READ-COMMITTED。用show variables来查看当前的值。

“可重复读”的场景：假设你在管理一个个人银行账户表，一个表存的每个月月底的余额，一个表存的账单明细，我们现在要判断上个月的余额和这个月余额的差值是否和本月的账单明细一致，这个时候我们肯定不希望此时如果有新的交易进而影响到我们的校对结果，这个时候就很适合使用“可重复读的”的隔离级别

事务的启动方式

MySQL的事务启动方式有以下几种：

1. 显示启动事务语句，begin或者start transaction。配套的提交语句是commit，回滚语句是rollback
2. set autocommit=0，这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个select语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行commit或rollback语句，或者断开连接。

建议总是使用set autocommit = 1 ， 通过显示语句的方式来启动事务。
对于频繁使用事务的业务，我们可以使用commit word and chain语法，每个事务在开始时都不需要主动执行一次“begin”，可以减少语句交互次数，在autocommit为1的情况下，用begin显式启动的事务，如果执行commit则提交事务。如果执行commit work andchain，则是提交事务并自动启动下一个事务，这样也省去了再次执行begin语句的开销。同时带来的好处是从程序开发的角度明确地知道每个语句是否处于事务中。

事务隔离的实现

我来看看事务隔离具体是怎么实现的。我们这里重点说一下“可重复读”。
在MySQL中，实际上每条记录在更新的时候都会同时记录一条回滚操作（其实这个就是undo log）。记录上的最新值，可以通过回滚操作，都可以得到前一个状态的值。

当前值是4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的read-view。如图中看到的，在视图A,B,C里面这一个记录的值分别是1,2,4；同一条记录在系统中可以存多个版本，这就是数据库的多版本并发控制（MVCC）.如果我们要得到1，我们就必须将当前的值依次执行图中所有的回滚操作得到。同时，即使现在有另外一个事务正在将4改成5，这个事务跟read-view A,B,C对应的事务是不会冲突的。
当系统里没有比某个回滚日志更早的read-view的时候，就会把这个回滚日志删除。

现在我们来想一下为什么尽量不要使用长事务。
长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。
除了回滚段的影响，长事务还占用锁资源，也可能拖垮整个库。

MVCC

在可重复读隔离级别下，事务在启动的时候就“拍了个快照”。注意：这个快照是基于整库的。（我们实际上并不需要拷贝整个数的数据，只要针对某个被修改了的行）。
transaction id：InnoDB里面每个事务有一个唯一的事务ID。他是在事务开始的时候向InnoDB的事务系统申请的，是按照申请顺序严格递增的。
而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记位row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到他。也就是说，数据表中的一行记录，其实可能有多个版本，每个版本都有自己的row trx_id.我们看看下图，就是一个记录被多个事务连续更新后的状态。

上面的虚线箭头，其实就是undo log，而V1,V2,V3并不是物理上真实存在的，而是每次需要的时候根据当前版本和undo log计算出来的。
根据可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。
因此，一个事务只需要在启动的时候拿到自己的一致性试图（一会下面会介绍），然后看看现在MySQL已存在的数据版本对比自己的一致性视图来决定自己认不认可这个数据版本（怎么判断符不符合一会介绍），如果不认，就通过undo log找到他的上一个版本。

一致性视图

当一个事务启动的瞬间就会拿到一致性视图
一致性视图：InnoDB为每个事务构造了一个数组，用来保存当前启动了但还未提交的事务ID，然后找到已经提交的事务的ID的最大值，还有找到当前已经存在的事务里面的最大值（无论他有没有提交）

数据版本如何和一致性视图对比

当一个事务的启动瞬间，一个数据版本的row trx_id，有以下几种可能：

1. row trx_id大于了当前已经存在的事务的最大值，那么这个row trx_id就是不可见的
2. row trx_id在数组中（里面存的是当前启动了但还未提交的事务ID），说明不可见
3. row trx_id不符合上面的情况下，小于等于当前已经提交的事务的ID的最大值，那么这个数据版本就是可见的

当然如果这个row trx_id是当前自己这个事务的话，当然也是可见的。
有了这个一致性视图后，系统里面随后发生的更新就和当前这个事务看到的内容无关了。因为之后的更新，生成的版本一定属于上面的1或者2的情况，而对他来说，这些新的数据版本是不存在的。
InnoDB利用了“所有数据都有多个版本”这个特性，实现了“秒级创建快照”的能力.

接下来我们分析一下事务A为什么读到的k是1

这里，我们做出如下假设：

1. 事务A开始前，系统里面只有一个启动还未提交的事务ID是99
2. 事务A,B,C的版本号分别是100，101，102，且当前系统里只有这四个事务
3. 三个事务开始前，（1（id），1(k)）这一行数据的row trx_id是90

这样，事务A的视图数据[99,100],事务B的视图数组是[99,100,101],事务C的视图数组是[99,100,101,102]

下面就是事务A查询数据的逻辑图：

首先事务C，把数据（1，1）改成了（1，2），这个数据的最新版本的row trx_id是102，而90这个版本已经成为了历史版本。
然后事务B，把数据（1，2）改成了（1，3）.这个数据的最新版本的row trx_id是101

这个事务A开始读数据了，他的视图数组是[99,100],高水位是100（即对事务A启动瞬间来说，已经创建过的事务id的最大值），已经提交的事务的最大值是98（假设是98，反正这个数一定要比99小）。

事务A的查询语句的读数据流程是这样的：

1. 找到（1，3）的时候，发现他的row trx_id为101，比事务A的高水位要大，不可见
2. 然后找到上一个历史版本（1，2），发现他的row trx_id为102，比事务A的高水位要大，不可见
3. 再往前找，找到了（1，1），他的row trx_id=90，发现他不大于高水位，然后发现他也不在事务A的视图数组中，并且他小于等于已经提交事务的最大值（98），所以对事务A来说是可见的

这样执行下来，虽然这期间这一行数据被修改过，但是事务A不论在什么时候查询，看到这行数据的结构都是一致的，所有我们称之为一致性读。

总结：
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：

1. 版本未提交，不可见
2. 版本已提交，但是在视图创建后提交的，不可见
3. 版本已提交，而且是在视图创建前提交的，可见

更新逻辑

我们再次回到这张图：

事务B的update语句，如果按照一致性读，结果和预期不一致。
事务B读的是（1，3）（正确），但是按照一致性读的话读的是（1，2）。
原因：当执行更新的时候，就不能在历史版本上更新了，否则事务C的更新就丢失了。因此事务B此时的set k=k+1 是在（1，2）的基础上进行的操作
所以，这里就用到了这样一条规则：更新数据都是很先读后写的，而这个读，只能读当前值（最新版本的值），称为当前读
因此，在更新的时候，当前读难道（1，2），更新成了（1，3），这个新版本的row trx_id就是事务B的id（101）
所以，在执行事务B查询语句的时候，会发现（1，3）的row trx_id和自己的事务id一致，所以查到的k的值是3

除了update语句外，select语句如果加锁，也是当前读。所以如果把事务A的查询语句改成下面这两种：

也都可以读到row trx_id是101的数据，返回k的值是3。这两个select 语句 ，就是分别加了读锁（共享锁） 和 写锁（排他锁）

我们来看看下面这种情况，事务C不是马上提交，而是变成了下面的事务C`:

事务C’的不同是，更新后并没有马上提交，在他提交之前，事务B的更新语句先发起了。虽然事务C’还没提交，但是（1，2）这个版本也生成了，并且是当前的最新版本。那么"两阶段锁协议"就来了：事务C‘没提交，也就是（1，2）这个版本的写锁还没释放。而事务B是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务C’释放这锁，才能继续他的当前读。

读提交的逻辑和可重复读的逻辑类似，他们的区别是：

1. 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图。
2. 在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。

总结：
可重复读的核心就是一致性读；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。