MySQL 事务一览

MySQL 中的事务？

对 MySQL 来说，事务通常是一组包含对数据库操作的集合。在执行时，只有在该组内的事务都执行成功，这个事务才算执行成功，否则就算失败。MySQL 中，事务支持是在引擎层实现的，像 MySQL 原生的 MyISAM 引擎就不支持事务，这也是被 InooDB 取代的重要原因。

为什么要有事务呢，举个例子来说，你的账户有 100 元，现在想给朋友转账 100 元。其中就会包含两个很重要的操作，你的账户减 100 元，朋友账户多 100 元。由于转账过程中出现失败是很常见的，假设操作不包含在事务内，你的账户减钱操作成功，朋友账户加钱操作失败。就会出现，你的账户扣钱，对方没有收到钱的情况。

再比如，在发起转账操作时，由于系统需要进行像查询余额，计算，更新余额的操作，如果在等待时间内，又发起了转账操作，但目前更新余额的操作还没有成功，就会出现你的 100 元，可以给别人转账多次的情况，这对于银行来说是肯定不允许的。

对于一个事务来说通常要满足四个特性，也就是通常所说的 ACID:

Atomicity - 保证在一个工作单元（就是一组操作）中所有的操作都执行成功，否则的话当前这个事务就会失败，之前的操作都被会回滚。
Consistency - 保证一个事务被成功提交后，数据库的状态是从一致性状态变成另一个一致性状态。
Isolation - 保证每个事务中的操作时是独立的，对于其他事务没有影响。
Durability - 对于已经提交的事务，即使在数据库损坏的情况下，也不会造成数据的丢失和损坏。

MySQL 中的事务隔离是如何实现的？

当数据库中有多个事务同时执行时，就可能会出现脏读，幻读，不可重复读的问题，为了解决这些问题，就出现了"隔离级别"的概念。

事务隔离的问题：

脏读：事务 A 中访问了事务 B 中未提交的数据。这里 Transaction 1 读到了，Transaction 2 中未提交的年龄数据。

不可重复读：事务 A 中多次查询同一数据，但由于事务 B 在事务 A 两次查询中，修改了改数据的值，导致两次查询的结果不一样。下面 Transaction 1 中的两次查询查询结果是一致的，第二次读到的 age 已经被修改的内容。

幻读：通常发生在事务 B 对事务 A 正在读取的内容，添加或删除了一条数据。造成数据莫名出现或者消失的情况。这里 Transaction 1 中，两次查询的结果并不一致，第二次查询会多出一条记录。

事务的隔离级别：

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

在 MySQL 中 RR 级别引入了间隙锁，解决了幻读的问题。

举一个实际的例子，来看一下这四种隔离级别对应的结果，假设表结构如下：

mysql> create table T(c int) engine=InnoDB;

insert into T(c) values(1);

此时发生的事务如下：

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

执行的效率会和执行的级别有关，隔离的越高，效率越低，需要在二者间寻找平衡。

事务隔离的应用场景？

读未提交：

这个基本没人会选择，连事务都构不成。

读提交：

一般互联网公司的隔离级别会选用这个，原因在：
- RR 级别下，存在间歇锁，出现死锁的几率比 RC 大的多。
- RR 级别下，条件列未命中索引会锁表。在 RC 级别下会锁行。
- RC 级别下，半一致性特性增加了 update 操作的并发性。

可重复读：

数据校验：假设你在管理一个个人银行账户表。一个表存了每个月月底的余额，一个表存了账单明细。这时候你要做数据校对，也就是判断上个月的余额和当前余额的差额，是否与本月的账单明细一致。你一定希望在校对过程中，即使有用户发生了一笔新的交易，也不影响你的校对结果。这时使用“可重复读”隔离级别就很方便。事务启动时的视图可以认为是静态的，不受其他事务更新的影响。

串行化：

每次读操作都会加锁，性能不佳。

事务隔离的实现？

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。

在可重复读时的隔离级别下，视图是在事务启动时创建的，整个事务存在期间都会用这个视图。
在读提交的隔离级别下，这个视图是在每个 SQL 语句开始执行时创建的。
在读未提交的隔离级别下，会直接返回记录的最新值，没有视图的概念。
串行化是直接通过加锁的方式来避免并行访问。

注意这个视图不是用于查询定义的虚拟表，而是在 InnoDB 中实现 MVCC 用到的一致性读视图（consistent read view），用于支持 RC 和 RR 隔离级别的实现。

可重复读的具体实现：

在 MySQL 中，实际上每条记录在更新时都会同时记录一条回滚操作。记录上的最新值，通过回滚都可以得到前一个状态的值。比如一个值从 1 按照顺序，被修改成 2、3、4 ，就会在回滚日志中有如下的记录。

当前最新是 4，在查询这条记录时，不同时刻启动的事务会有不同的 read-view. 在视图 A B C 中，记录值为 1, 2, 4. 同一条记录可以存在多个版本，这就是数据库多版本并发控制（MVCC）。对于 read-view A 来说，要得到 1，就必须将当前值依次执行图中所有的回滚操作得到。假如，有另外一个事务将 4 改成 5，但对于视图 A B C 来说，事务是不冲突的。

回滚段的删除，为什么要避免使用长事务？

既然每一条记录都会更新是都会产生一条回滚操作记录，时间一长，肯定会占用大量的存储空间。那么系统会在什么时候删除这些回滚日志呢，就是在当前系统里不存在比该回滚日志更早的 read-view 时。

但如果系统里存在着很老的事务视图。由于这些事务可能会访问数据库里的任何数据，所以在事务提交之前，所有可能用到的回滚记录都必须保留，这就可能出现占用大量存储空间的情况。

在 MySQL 5.5 之前，回滚日志和数据字典一起放在 ibdata 文件里，即使长事务被提交，回滚段被清理，文件也不会变小。

并且长事务还占用锁资源，也可能拖垮整个库。

MySQL 中事务的启动方式？

显式启动事务：

# 使用 START TRANSACTION 或者 BEGIN 开启事务：

START TRANSACTION

    [transaction_characteristic [, transaction_characteristic] ...]

transaction_characteristic: {

    WITH CONSISTENT SNAPSHOT

  | READ WRITE

  | READ ONLY

}

BEGIN [WORK]

# 使用 COMMIT 来提交事务

COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]

# 使用 ROLLBACK 来回滚事务

ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]

隐式启动事务：

# 设置当前事务的是否自动提交

SET autocommit = {0 | 1}

autocommit 的讨论：

当 autocommit=0 时，事务启动后，不会自动关闭直到主动的输入 COMMIT 或者 ROLLBACK 语句，或者断开连接时，当前事务才结束。
- 一些客户端连接框架会默认连接成功后先执行一个 set autocommit=0 的命令。这就导致接下来的查询都在事务中，如果是长连接，就导致了意外的长事务。
当 autocommit=1 时，建议总是以这种方式启动事务。
- 如果担心多一次交互的问题，可以使用 commit work and chain 语法。

多一次交互的问题，如果采用 autocommit=0 的这种方式，不需要每次输入 begin ，减少了语句的交互次数。

查询长事务：

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

避免长事务的方案：

在开发过程中，减少事务范围，少用长事务。如果无法避免，保证逻辑日志空间够用，并且支持动态日志空间的增长。
监控Innodb_trx表，发现长事务报警。

总结

在开始部分，介绍了 MySQL 中事务的概念，并回顾了事务的 ACID 的特性。接着探讨了事务隔离的可能出现的脏读，不可重复读以及幻读的问题，并给出了相应的解决方案-隔离级别。并分析了常见事务隔离的应用场景以及事务隔离的实现方式。

并在最后引出了回滚段的概念，以及为什么要避免使用长事务。并给出了开启事务的方法。

参考