MySQL事务详解

1. MySQL事务

什么是mysql事务，这个问题如果从正面你直接回答，其实并不能很直观的描述其概念，相信很多人都会通过一个很经典的转账案例来描述什么是事务，例如，你给朋友转100块钱，按照正常的操作流程是你的账户减去100块钱，朋友的账户增加100块钱，本身这两个操作是完全独立的两次数据库更新操作，现在如果你的账户扣减100块钱成功，但是你朋友的账户增加100块失败，或者你的账户扣减成功，你朋友的账户增加失败，就会出现数据对不上的问题。现在问题出现了，怎么解决，数据库事务，把这两个操作放到一个事务内执行，要么全部成功，要么全部失败，从而避免数据对不上的问题，这个问题解决了，这就是事务。

简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。你现在知道，MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。

2. 事务四大特性

事务四大特性ACID（Atomicity、Consistency、Isolation、Durability，即原子、一致、隔离、持久性）

原子性(atomicity)： 事务的最小工作单元，要么全成功，要么全失败。
一致性(consistency)： 事务开始和结束后，数据库的完整性不会被破坏。
隔离性(isolation)： 不同事务之间互不影响，四种隔离级别为RU（读未提交）、RC（读已提交）、RR（可重复读）、SERIALIZABLE （串行化）。
持久性(durability)： 事务提交后，对数据的修改是永久性的，即使系统故障也不会丢失。
1
2
3
4

3. 事务隔离级别

3.1 事务隔离级别

READ-UNCOMMITTED(读取未提交) ： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
READ-COMMITTED(读取已提交) ： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
REPEATABLE-READ(可重复读) ： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
SERIALIZABLE(可串行化) ： 最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
1
2
3
4

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）。
Oracle 默认隔离级别是READ-COMMITTED(读取已提交)。

3.2 事务使用场景

mysql提供了四种事务隔离级别，并不是说那种好或者不好，每个隔离级别都有自己的应用场景，比如说银行的对账系统，当月月初要统计上月的交易记录，本身上月的交易记录是不可变更的静态数据，即使当月有新的交易记录并不影响你的校对结果，所以也没有必要串行化或者其隔离级别影响其性能，而在电商中下单扣库存支付的场景中却要保证其避免脏读幻读与不可重复读的问题。

3.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的时候。基于上面的说明，我们来讨论一下为什么建议你尽量不要使用长事务。

长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。在MySQL 5.5及以前的版本，回滚日志是跟数据字典一起放在ibdata文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小。我见过数据只有20GB，而回滚段有200GB的库。最终只好为了清理回滚段，重建整个库。除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库，这个我们会在后面讲锁的时候展开。

3.4 事务的启动方式

如前面所述，长事务有这些潜在风险，我当然是建议你尽量避免。其实很多时候业务开发同学并
不是有意使用长事务，通常是由于误用所致。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
1

4. Spring事务

前面介绍了mysql数据库事务，更精确的来说是innoDB的事务，而在实际的项目应用过程中很少是直接通过操作数据实现其事务特性，而是结合Spring框架来实现的，而spring框架本身是不具有事务特性，所有这里面有些误会，很多人提到的所谓的Spring事务，本质上是指MySQL的innoDB的事务，指的是Spring依赖于InnoDB实现的事务。

Spring事务具体参考：Spring框架详解-Spring事务章节