MySQL的事务隔离级别和长事务，看这一篇就够了

提到事务，你们都不陌生，在使用数据库的时候，咱们总会提到事务，最经典的例子就是转账，好比小王的银行卡上有一百块，要把这一百块转帐，转帐过程当中的一系列操做，好比查询余额、扣减资金、增长资金、更新余额等，这些操做必须保证是一体的，否则等查询余额以后，在扣除资金以前，彻底能够借着这个时间再查一次，而后将这个钱转给另一我的，这样不就乱套了。

事务的概念各位都不陌生，简单来讲，事务就是要保证一组数据库操做，要么所有成功，要么所有失败。MySQL数据库的事务支持是在引擎层实现的。MySQL是一个支持多引擎的系统，可是不是全部的引擎都支持事务，只有InnoDB支持事务。

隔离性与隔离级别

你们都都知道事务的四种属性ACID，今天咱们就说说其中的 I，也就是隔离性。

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

事务的隔离等级越高，效率就会越低，不少时候咱们就在数据准确和效率之间找平衡点。SQL标准的事务隔离级别包括：读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（serializable）。可能不少人已经对这几个概念很熟悉，这里就简单介绍一下：

• 读未提交：一个事务还没提交时，它作的变动就能被其余事务看到。

• 读提交：一个事务只有在提交以后，其它事务才能看到它作的变动。

• 可重复读：一个事务执行过程当中看到的数据，老是跟这个事务在启动时看到的数据是一致的，在可重复读隔离级别下，未提交变动对其它事务也是不可见的。

• 串行化：顾名思义是对同一行记录，“写”会加“写锁”，“读”会加“读锁”，当读写锁冲突的时候，后访问的事务必须等前一个事务执行完成才能继续执行。

下边经过一个例子来讲明几个隔离级别，先准备一张表T，其中一行的值为1 ,按照时间顺序执行两个事务的行为：

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

下边咱们来看看不一样的隔离级别下，事务A的各个查询的结果，也就是V1，V2，V3的返回值分别是什么。

• 隔离级别是“读未提交”，则V1的值是2，这个时候虽然事务B尚未提交，可是结果已经被事务A看到了，因此V2，V3也都是2.

• 隔离级别是“读提交”，则V1的值是1，查询V2的时候事务B已经提交，因此事务B的更新事务A是能够看到的，因此V２是２，Ｖ３也是２。

• 隔离级别是“可重复读”，则V一、V2是1，V3是2，为何V2仍是1，是由于事务在执行期看到的数据先后必须是一致的。

• 隔离级别是“串行化”，在事务B执行将1改成2的时候，会被锁住，等事务A执行完提交后，事务B才能够继续执行，因此从事务A的角度来看，V一、V2值是1，V3的值是2.

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

咱们能够根据须要来修改MySQL的隔离级别，如咱们要将MySQL的隔离级别设置为”读提交“，配置的方式是，将启动参数transaction-isolation的值设置成READ-COMMITTED,能够用show variables来查看当前的值。

mysql> show variables like 'transaction_isolation';
+-----------------------+----------------+
| Variable_name | Value |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+

事务隔离的实现

上边咱们了解了事务的隔离级别，咱们再来看看事务隔离具体是怎么实现的。这里咱们来详细说说”可重复读“，在MySQL中，实际上每条记录在更新的时候都会同时记录一条回滚操做，记录上的最新值，经过回滚的方式均可以获得前一个状态的值。

假设一个值从1被依次改为了二、三、4，在回滚日志（undo log）里就会有相似下边的记录。

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

这个时候你会发现，即便如今另一个事务正在将4改成3，这个事务跟read-viewA、B、C对应的事务是不会冲突的。

回滚日志的保留时间，在不须要的时候才会删除，系统判断，没有其余事务线程还在使用当前版本的undo的时候，purge进程进行回收。

基于上边的说明，咱们来讨论一下大佬们常说的尽可能不使用长事务是为何？

长事务意味着系统里面会存在很老的事务视图，因为这些事务随时可能访问数据库里面的任何数据，因此这个事务提交以前，数据库里面它可能用到的回滚记录都必须保留，这就致使了大量占用内存。在MySQL5.5之前的版本，回滚日志是和数据字典一块儿放在ibdata文件里的，即便长事务提交，回滚段被清理，文件也不会变小，最终每每为了清理回滚段而重建整个库。除了影响回滚段，长事务还会占用锁资源，也有可能拖垮整个库。

事务的启动方式

长事务的潜在风险咱们上边已经聊过了，建议是尽量的避免，其实不少长事务，并非有意使用，都是被误用所致，下边咱们聊聊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. 事务的概念是什么?

2. mysql的事务隔离级别读未提交, 读已提交, 可重复读, 串行化是什么意思?

3. 读已提交, 可重复读是怎么经过视图构建实现的?

4. 可重复读的使用场景举例? 对帐的时候应该颇有用?

5. 事务隔离是怎么经过read-view(读视图)实现的?

6. 并发版本控制(MCVV)的概念是什么, 是怎么实现的?

7. 使用长事务的弊病? 为何使用常事务可能拖垮整个库?

8. 事务的启动方式有哪几种?

9. commit work and chain的语法是作什么用的?

10. 怎么查询各个表中的长事务?

11. 如何避免长事务的出现?