现在常规的应用系统中，每一个接口基本都需要执行多条更新SQL。这就要求多条SQL的更新要么全部生效，要么全部都不生效。这就是所谓的原子性，事务的四大特性之一。MySQL原生的存储引MyISAM是不支持事务的，因此大部分场景都需要用InnoDB存储引擎，其也是新版MySQL的默认存储引擎。
事务之ACID特性
Atomicity-原子性
Consistency-一致性
Isolation-隔离性
Durability-持久性
隔离级别是为了解决多个事务同时执行过程中，会出现的脏读，不可重复读和幻读问题
脏读-Dirty Read
读到了其他事务未提交的更新，当那个事务回滚后，这条更新就是脏数据了。
不可重复读-Nonrepeatable Read
针对同一条数据，第一次读的时候还未提交，第二次再读的时候，已经提交了，所以读到了。
幻读-Phantom Read
针对范围查询，第二次再读的时候，其他事务提交了一条更新，在这个范围内。对当前事务来说，
第二次读的时候，比第一次读的时候多了一条数据。
针对上面每种问题，数据库规范？定义了四种隔离级别
READ_UNCOMMITED
当前事务可以看到其他事务未提交的更新
READ_COMMITED
当前事务只能读到其他事务已提交的更新
REPEATABLE_READ
当前事务中任何时刻读取的数据都一致，即使其他事务的更新已经提交了
SERIALIABLE
事务串行
各种隔离级别的实现方案，事务访问的数据都是以视图的逻辑结果为准。在REPEATABLE_READ隔离 级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在READ_COMMITED隔离级 别下，这个视图是在每个SQL语句开始执行的时候创建的。这里需要注意的是，READ_UNCOMMITED隔离级别下直接返回记录上的最新值，没有视图概念;而SERIALIABLE隔离级别下直接用加锁的方式来避 免并行访问。
综上，为解决多事务并发问题，针对不同问题采用不同的解决方案
1.MVVC-Multi Version Currency Control,利用undo log实现的视图逻辑结果，具体实现方案见[https://www.jianshu.com/p/f692d4f8a53e
2.加锁，使事务串行执行
问题：在具体实现中，两种方案是怎么配合使用的？
试验，在实际试验不同事务隔离级的效果时，可以直接写SQL试验。
开启事务的方式有以下两种
begin;(或者 start transaction;)
sql statement;
commit; (回滚 rollback;)
set autocommit=0
开启了事务，怎么指定事务隔离级别。在MySQL中，事务隔离级别有
全局级
SELECT @@global.tx_isolation;
会话级
SELECT @@session.tx_isolation;
所有的？？？
SELECT @@tx_isolation;
设置事务隔离的命令（不区分大小写）
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}
例如给当前连接上的事务设置隔离为读未提交
set session transaction isolation level read uncommited
如果不指定session 或者global,则设置对下一个事务生效。（不是太懂）
试验一把，在一个连接中更新，但是不提交，在另一个连接中，设置事务隔离级别为read uncommited 然后查询，看是否能看到更新。果然能看到。
有个问题，每一条SQL都是在事务下执行的。就算对于一个select语句来讲，也是在事务中的，因为当前的事务隔离级别决定了他能看到什么样的数据。
所谓只读事务是什么概念？？
官方文档更能直至本质https://dev.mysql.com/doc/refman/5.7/en/innodb-autocommit-commit-rollback.html
一直讲事务隔离级别，但是忽略了一个重要的概念，那就是autocommit。
根据上面的官方文档，所有的用户行为（我的理解是执行的任何DML语句）都是在事务里的（跟我上面的理解是一致的，哈哈哈）。如果开启了autocommit，每一个单独的SQL都会产生一个属于它自己的事务，所以SQL执行成功后（当错误后的处理策略再研究），MySQL就会自动执行commit操作。默认情况下，autocommit是开启的。所以我们执行完update insert等语句后，数据会及时持久化到磁盘。问题来了，如果关闭autocommit会有什么影响，这个配置是session级还是全局级的？
第二个问题，通过试验(set autocommit =0;)得出结论，关闭autocommit只在当前session中生效，其他session不受影响。
第一个问题，还是根据官方文档，如果关闭autocommit，一个session默认会开启事务，直到用户执行了commit或者rollback后，才会结束这个事务，并且再开启一个新事务。
综上，要想将多个SQL明确放在一个事务中，便于统一提交或者回滚，有两种方式
方式一、关闭autocommit，所有SQL执行完之后，再commit或者rollback。
方式二、在执行第一条SQL前，执行begin或者start transaction,所有SQL执行完之后，再commit或者rollback。
所以任何一条DML语句都是在事务中执行的，区别在于事务的范围（即包含了哪些SQL）以及事务的提交或者回滚执行的时刻。讲到这里，发现事务跟线程的概念相似，任何一段代码都是在某个线程中执行的，要么自己指定用哪个线程，要么就是系统提供的主线程。
