MySQL实战之事务隔离：为什么你改了我还看不见

1.前言

在我们使用数据库的过程中，不可避免的要和事务打交道，而讲解事务最经典的案例就是转账，例如：你要给朋友小刘转账100元，而且你只有100元。

转账要经过一系列的操作，比如查询余额，发起转账，扣除余额，这些操作都必须保持是原子的，要不然可能还没有在扣除余额的时候，完全可以利用这个时间，在给其他人转账，这样输入和输出的金额就对不上了，银行就会混乱了，这时候就可以利用事务来解决该问题。

简单的说，事务就是保证一组数据库操作，要么全部成功，要么全部失败，在MySQL中，事务是由存储引擎实现的，InnoDB就支持事务，MyISAM不支持事务，这也是InnoDB代替MyISAM的一个重要原因

2.隔离性和隔离级别

大家提及事务，第一时间想到的应该就是ACID（Atomicity、Consistency、Isolation、Durability），即原子性，一致性，隔离性和持久性。

原子性（Atomicity）：一组操作，要么全部成功，要么全部失败

一致性（Consistency）：对一组操作前后，数据会保持一致，比如小红给小刘转账一百元，转账前小红有100元，转账后小刘收到100元，100元不会发生改变，只是看在谁的口袋里

隔离性（Isolation）：多个事务之间的互相干扰

持久性（Durability）：一个事务一旦提交成功，数据库就可以持久化到磁盘，后面的其他操作都不会产生影响

今天就着重介绍一下隔离性，事务隔离性存在的三个问题

脏读：一个事务读取到了另一个未提交事务的数据

不可重复读：一个事务读取到了另一个已提交事务的数据

幻读：一个事务读取了另一个已提交事务的插入数据

事务的隔离级别分为四种，分别是

读未提交（read uncommitted）:一个事务还没有提交，它做的变更就可以被别的事务看到

读已提交(read committed)：一个事务提交后，它做的变更才可以被其他事务看到

可重复读(repeatable read)：一个事务执行过程中看到的数据，总是跟这个事务启动时看到的数据是一致的。

串行化(serializable)：对于同一行记录，“写”会加“写锁”，“读”会加”读锁“。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能执行。

效率对比：读未提交>读已提交>可重复读>串行化；事务隔离级别越高，效率就越低，MySQL默认的隔离级别是可重复读，oracle默认的隔离级别是读已提交。

接下来通过一个例子讲解一下几种隔离级别，假设数据表T中只有一列，其中一行的值为1，下面按照时间顺序执行两个事务的行为

create table T(c int) engine=innodb;
insert into T(c) values(1);

在这里插入图片描述

读未提交：V1、V2和V3都是2，因为事务A可以读取到事务B还没有提交的数据，所以V1=2

读已提交：V1是1，V2和V3是2，因为事务A可以读取到事务B已提交的数据，所以V1=1，V2=2

可重复读：V1和V2是1，V3是2，因为事务A执行前后读取的数据必须是一直的

串行化：V1和V2是1，V3是2，事务B会被事务A卡主，知道事务A执行完成，才会执行事务B

我们可以通过一下命令查看当前数据库的隔离级别

show variables like 'transaction_isolation'
	Variable_name 	  |      Value 
transaction_isolation | READ-COMMITTED

具体在实际应用中，我们应该设置成什么样的隔离级别呢，我只能说，要根据具体的业务情况来定，大部分情况下用数据库自带的隔离级别就够用了

3.事务隔离的实现

了解了事务的隔离级别，我们再来看看事务隔离具体是如何实现的，这里我们主要围绕可重复读讲解。

在MySQL中，实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。

假设一个值从1被按照顺序改成了2，3，4，在回滚日志里面就会有类似下面的记录

在这里插入图片描述

当前值是4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的read-view。如图中看到的，在事务A、B、C里面，这一个记录值分别是1、2、4，同一条记录在系统中可以存在多个版本，就是数据库多版本并发控制（MVCC）。对于read-viewA，要得到1，就必须将当前值依次执行图中所有的回滚操作。

同时你会发现，即使现在有另外一个事务正在将4改成5，这个事务跟read-viewA、B、C对应的事务是不会冲突的。

你一定会问，回滚日志总不能一直保留吧，什么时候删除呢？答案是，在不需要的时候才删除。也就是说，系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志才会删除。

什么时候才不需要呢？就是当系统没有比这个回滚日志更早的read-view的时候。

基于上面的说明，我们来讨论一下为什么建议你尽量不要使用长事务。

长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须要保留，这就会导致大量占用存储空间。

除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库，这个我们会在后面讲锁的时候展开。

4.事务的启动方式

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

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

因此，我建议要使用set autocommit=1,通过显示语句的方式启动事务。

你可以在information_schema库的innodb_trx这个表中查询长事务，比如下面这个语句，用于查找持续时间超过60s的事务

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

5.小结

这篇文章里面，我介绍了 MySQL 的事务隔离级别的现象和实现，根据实现原理分析了长事务存在的风险，以及如何用正确的方式避免长事务。希望我举的例子能够帮助你理解事务，并更好地使用 MySQL 的事务特性。