提到事务，大家都不陌生，在使用数据库的时候，我们总会提到事务，最经典的例子就是转帐，比如小王的银行卡上有一百块，要把这一百块转账，转账过程中的一系列操作，比如查询余额、扣减资金、增加资金、更新余额等，这些操作必须保证是一体的，不然等查询余额之后，在扣除资金之前，完全可以借着这个时间再查一次，然后将这个钱转给另外一个人，这样不就乱套了。
事务的概念各位都不陌生，简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。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２是２，Ｖ３也是２。
- 隔离级别是“可重复读”，则V1、V2是1，V3是2，为什么V2还是1，是因为事务在执行期看到的数据前后必须是一致的。
- 隔离级别是“串行化”，在事务B执行将1改为2的时候，会被锁住，等事务A执行完提交后，事务B才可以继续执行，所以从事务A的角度来看，V1、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被依次改成了2、3、4，在回滚日志（undo log）里就会有类似下边的记录。
当前值是4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的
read-view，如图中看到的，在视图A、B、C里面，这个记录的值分别是1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。对于read-viewA，要想得到1，就必须将当前值依次执行图中所有的回滚操作得到。
这个时候你会发现，即使现在另外一个事务正在将4改为3，这个事务跟read-viewA、B、C对应的事务是不会冲突的。
回滚日志的保留时间，在不需要的时候才会删除，系统判断，没有其他事务线程还在使用当前版本的undo的时候，purge进程进行回收。
基于上边的说明，我们来讨论一下大佬们常说的尽量不使用长事务是为什么？
长事务意味着系统里面会存在很老的事务视图，由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就导致了大量占用内存。在MySQL5.5以前的版本，回滚日志是和数据字典一起放在ibdata文件里的，即使长事务提交，回滚段被清理，文件也不会变小，最终往往为了清理回滚段而重建整个库。除了影响回滚段，长事务还会占用锁资源，也有可能拖垮整个库。
事务的启动方式
长事务的潜在风险我们上边已经聊过了，建议是尽可能的避免，其实很多长事务，并不是有意使用，都是被误用所致，下边我们聊聊MySQL的事务启动方式：
- 显示启动事务语句，begin或者start transaction。配套的提交语句是commit，回滚语句是rollback。
- 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.如何避免长事务的出现?
