#技术人为什么写博客# MySQL事务--第一篇

一、概念

事务到底是什么东西呢？想必大家学习的时候也是对事务的概念很模糊的。接下来通过一个经典例子讲解事务。

银行在两个账户之间转账，从​​A​​​账户转入B账户1000元，系统先减少A账户的1000元，然后再为​​B​​账号增加1000元。如果全部执行成功，数据库处于一致性；

如果仅执行完​​A​​​账户金额的修改，而没有增加​​B​​账户的金额，则数据库就处于不一致状态，这时就需要取消前面的操作。

这过程中会有一系列的操作，比如余额查询，余额做加减法，更新余额等，这些操作必须保证是一个整体执行，要么全部成功，要么全部失败，不能让​​A​​​账户钱扣了，但是中途某些操作失败了，导致​​B​​账户更新余额失败。这样用户就不乐意了，银行这不是坑我吗？

“

事务就是要保证一组数据库操作，要么全部成功，要么全部失败。

在MySQL中，事务支持是在引擎层实现的。你现在知道，MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。

比如MySQL原生的​​MyISAM​​​引擎就不支持事务，这也是MyISAM被​​InnoDB​​取代的重要原因之一。

接下来会以​​InnoDB​​为例，抽丝剥茧MySQL在事务支持方面的特定实现。

二、隔离性与隔离级别

提到事务，你肯定会想到​​ACID​​​（​​Atomicity​​​、​​Consistency​​​、​​Isolation​​​、​​Durability​​，即原子性、一致性、隔离性、持久性），接下来我们就要讲解其中的I，也就是隔离性。

当数据库上存在多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题，为了解决这些问题，就有了隔离级别的概念。

我们知道，隔离级别越高，效率就越低，因此我们很多情况下需要在二者之间找到一个平衡点。

SQL标准的事务隔离级别包括：

1. 读未提交（read uncommitted）
2. 读提交（read committed）
3. 可重复读（repeatable read）
4. 串行化（serializable ）

下面我逐一为你解释：

1. 读未提交：事务中的修改，即使没有提交，对其他事务也都是可见的，事务可以读取未提交的数据，也被称为​​脏读​​。这个级别会导致很多问题，从性能上来说也不会比其他隔离级别好很多，但却缺乏其他级别的很多好处，一般实际应用中很少用，甚至有些数据库内部根本就没有实现。
2. 读已提交：事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的，这个级别有时候也叫做​​不可重复读​​（Nonrepeatable Read）,因为同一事务中两次执行同样的查询，可能会得到不一样的结果
3. 可重复度：同个事务中多次查询结果是一致的，解决了不可重复读的问题。此隔离级别下还是无法解决另外一个​​幻读​​（Phantom Read）的问题，幻读是指当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，之前的事务再次读取该范围的记录时，会产生幻行
4. 串行化：顾名思义是对于同一行记录，​​写​​​会加​​写锁​​​，​​读​​​会加​​读锁​​。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

对于上面的概念中，可能 读已提交 和可重复读比较难理解，下面会用一个例子说明这种集中隔离级别。假设数据表​​T​​​中只有一列，其中一行的值为​​1​​，下面是按照时间顺序执行两个事务的行为。

mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);

接下来讲解不同的隔离级别下，事务A会有哪些不同的返回结果，也就是图里面​​V1​​​、​​V2​​​、​​V3​​的返回值分别是什么。

1. 若隔离级别是读未提交， 则​​V1​​​的值就是​​2​​​。这时候​​事务B​​​虽然还没有提交，但是结果已经被​​A​​​看到了。因此，​​V2​​​、​​V3​​​也都是​​2​​。
2. 若隔离级别是读提交，则​​V1​​​是1，​​V2​​​的值是2。​​事务B​​的更新在提交后才能被A看到。所以， V3的值也是2。
3. 若隔离级别是可重复读，则​​V1​​​、​​V2​​​是1，​​V3​​​是2。之所以​​V2​​还是1，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。
4. 若隔离级别是串行化，则在​​事务B​​​执行“将1改成2”的时候，会被锁住。直到​​事务A​​​提交后，​​事务B​​​才可以继续执行。所以从​​A​​​的角度看， ​​V1​​​、​​V2​​​值是1，​​V3​​的值是2。

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在可重复读隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。

在读提交隔离级别下，这个视图是在每个SQL语句开始执行的时候创建的。这里需要注意的是，读未提交隔离级别下直接返回记录上的最新值，没有视图概念；而串行化隔离级别下直接用加锁的方式来避免并行访问。

注意一下，每种数据库的行为会有所不一样，​​Oracle​​数据库的默认隔离界别是读提交，因此，当我们需要进行不同数据库种类之间迁移的时候，为了保证数据库隔离级别的一致，切记将MYSQL的隔离级别设置为读提交。

配置的方式是，将启动参数​​transaction-isolation​​​的值设置成​​READ-COMMITTED​​​。你可以用​​show variables​​来查看当前的值。

每种隔离级别都有它自己的使用场景，你要根据自己的业务情况来定。我想你可能会问那什么时候需要“可重复读”的场景呢？我们来看一个数据校对逻辑的案例。

假设你在管理一个个人银行账户表。一个表存了每个月月底的余额，一个表存了账单明细。这时候你要做数据校对，也就是判断上个月的余额和当前余额的差额，是否与本月的账单明细一致。你一定希望在校对过程中，即使有用户发生了一笔新的交易，也不影响你的校对结果。

这时候使用可重复读隔离级别就很方便。事务启动时的视图可以认为是静态的，不受其他事务更新的影响。

三、事务隔离的实现

接下来以可重复度来展开事务隔离具体是怎么实现的。

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

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

可以看到当前值是4，从图中可以看到在查询的时候，不同时刻启动的事务会有不同的​​read-view​​​。如图中看到的，在视图​​A​​​、​​B​​​、​​C​​里面，这一个记录的值分别是1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。

对于read-view A，要得到1，就必须将当前值依次执行图中所有的回滚操作得到。同时你会发现，即使现在有另外一个事务正在将4改成5，这个事务跟read-view A、B、C对应的事务是不会冲突的。

你一定会问，回滚日志总不能一直保留吧，什么时候删除呢？

这是肯定不能一直保留的，在不需要的时候才删除。系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志会被删除。

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

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

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

在​​MySQL 5.5​​​及以前的版本，回滚日志是跟数据字典一起放在​​ibdata​​​文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小。我见过数据只有​​20GB​​​，而回滚段有​​200GB​​的库。最终只好为了清理回滚段，重建整个库。

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

四、事务启动方式

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

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

有些客户端连接框架会默认连接成功后先执行一个​​set autocommit=0​​的命令。这就导致接下来的查询都在事务中，如果是长连接，就导致了意外的长事务。

因此，我会建议你总是使用​​set autocommit=1​​, 通过显式语句的方式来启动事务。

但是有的开发同学会纠结多一次交互的问题。对于一个需要频繁使用事务的业务，第二种方式每个事务在开始时都不需要主动执行一次 ​​begin​​​，减少了语句的交互次数。如果你也有这个顾虑，我建议你使用​​commit work and chain​​语法。

在​​autocommit​​​为1的情况下，用​​begin​​​显式启动的事务，如果执行​​commit​​​则提交事务。如果执行 ​​commit work and chain​​​，则是提交事务并自动启动下一个事务，这样也省去了再次执行​​begin​​语句的开销。同时带来的好处是从程序开发的角度明确地知道每个语句是否处于事务中。

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

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

五、MVCC工作原理

可重复读隔离级别下，事务在启动的时候就“拍了个快照”。请注意，这个快照是基于整个库的，这时候你肯定觉得不可思议，如果一个库上百G的数据，那么我启动一个事务，那MYSQL岂不是要将上百G的数据拷贝出来，这个过程不是非常慢吗？但是为什么我们平时并没有感觉到它