事务的使用场景
最经典的例子就是银行转账，用户从a账户转200元到b账户，那么就会产生3个操作 1.检查a账户余额是否够200元 2.a账户减少200元 3.b账户增加200元。这些操作必须保证是一体的，负责用户就会根据时间差进行多次转账。
具体sql实现如下：
mysql的四种隔离级别
- 读未提交 一个事务还未提交，它做的变更就能被别人看到
- 读提交 一个事务提交后，它做的变更才会被其他人看到
- 可重复读 一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。
- 串行化 对同一行记录，写会加锁，读也会加锁。当出现读写冲突是，总是会等前一个事务解锁，后访问的事务才能继续执行。
隔离级别解决的问题如下图所示
#隔离级别产生读写问题的原因
脏读
如果一个事务读到了另一个未提交事务修改过的数据
这时候事务B虽然还没有提交，但是结果已经被A看到了
不可重复读
如果一个事务只能读到另一个已经提交的事务修改过的数
据，并且其他事务每对该数据进行一次修改并提交后，该事务都能查询得到最新值
事务B的更新在提交后才能被A看到
幻读
如果一个事务先根据某些条件查询出一些记录，之后另一个事务又向表中
插入了符合这些条件的记录，原先的事务再次按照该条件查询时，能把另一个事务插入的记录也读出来
V1、V2是1，V3是2。之所以V2还是1，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。
阻止事务错误读写的逻辑
**数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。**在"可重复读"隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都在用这个视图。在"读提交"隔离级别下，这个视图是在每个SQL语句开始执行的时候创建的。"读未提交"隔离级别下直接放回记录上的最新值，没有视图概念；而"串行化"隔离级别直接用加锁的方式来避免进行访问。
Oracle数据库的默认隔离级别其实就是“读提交”
修改事务隔离级别
SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL level;
事务隔离(可重复读)的实现
所有的事务都是在InnoDB中实现的因为MyISAM不支持事务
MVCC多版本并发控制
- MVCC的实现，是通过保存数据在某个时间的快照来实现的。不管需要执行多长时间，事务看的数据是一样的。
- 根据事务开始的时间不同，每个事务对一张表，同一时刻看的数据是不同的。
例子：假设一个值从1被按顺序改成了2、3、4，如下图所示：
当前值是4，但是再查询这条记录的时候，不同时刻启动的事务会有不同的read-view(后续文章详细解释)。如图所示，在视图A,B,C里面分别记录不同值，及同一条记录存在多个版本。对于read-view A，要得到1，就必须将当前值依次执行图中所有的回滚操作得到。
同时你会发现，即使现在有另外一个事务正在将4改成5，这个事务跟read-view A、B、C对应的事务是不会冲突的。
事务的启动方式
- 显式启动事务语句，begin或start transaction。配套的提交语句是commit，回滚语句是rollback。
- set autocommit=0，这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个select语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行commit 或 rollback 语句，或者断开连接。
有些客户端连接框架会默认连接成功后先执行一个set autocommit=0的命令。这就导致接下来的查询都在事务中，如果是长连接，就导致了意外的长事务。
长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。
set autocommit=1, 通过显式语句的方式来启动事务