事务的隔离级别与所带来的问题
一、事务的基本要素（ACID）
1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
2、一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。
3、隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。
4、持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。
二、SQL标准的事务隔离级别(mysql默认为可重复读,oracle默认为读已提交)
- 读未提交（read uncommitted）是指，一个事务还没提交时，它做的变更就能被别的事务看到。
- 读已提交（read committed）是指，一个事务提交之后，它做的变更才会被其他事务看到。
- 可重复读（repeatable read）是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
- 串行化（serializable ），顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。
例子
| 事务一 | 事务二 |
|---|---|
| 启动事务A,查询A=10 | 启动事务B |
| 查询A=10, 更新A=20 | |
| 查询值a1 | |
| 提交事务B | |
| 查询值a2 | |
| 提交事务A | |
| 查询值a3 |
-
若隔离级别是“读未提交”， 则a1的值就是20,虽然B没提交2但是结果已经A看到了
-
若隔离级别是“读已提交”，则a1是10，a2的值是2。事务B的更新在提交后才能被A看到。所以， a3的值也是2。
-
若隔离级别是“可重复读”，则a1、a2是10，a3是20。之所以a2还是10，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。
-
若隔离级别是“串行化”，则在事务B执行“将A=10改成20”的时候，会被锁住。直到事务A提交后，事务B才可以继续执行。所以从A的角度看， a1、a2值是10，a3的值是20
三、如何设置和查看隔离级别
- 读未提交:read uncommitted
- 读已提交:read committed
- 可重复读:repeatable read
- 串行化:serializable
查看隔离级别
show variables like 'transaction_isolation';
设置innodb的事务级别方法是：set 作用域 transaction isolation level 事务隔离级别，例如~
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}
set global transaction isolation level read committed; //全局的
set session transaction isolation level read committed; //当前会话
四、事务隔离级别所带来的问题
这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：
脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。
不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。
幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。
解决方案
//todo
补充
-
事务隔离的实现：每条记录在更新的时候都会同时记录一条回滚操作。同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）。
-
回滚日志什么时候删除？系统会判断当没有事务需要用到这些回滚日志的时候，回滚日志会被删除。
-
什么时候不需要了？当系统里么有比这个回滚日志更早的read-view的时候。
-
为什么尽量不要使用长事务。长事务意味着系统里面会存在很老的事务视图，在这个事务提交之前，回滚记录都要保留，这会导致大量占用存储空间。除此之外，长事务还占用锁资源，可能会拖垮库。
-
事务启动方式：
- 一、显式启动事务语句，begin或者start transaction,提交commit，回滚rollback；
- 二、set autocommit=0，该命令会把这个线程的自动提交关掉。这样只要执行一个select语句，事务就启动，并不会自动提交，直到主动执行commit或rollback或断开连接。
- 建议使用方法一，如果考虑多一次交互问题，可以使用commit work and chain语法。在autocommit=1的情况下用begin显式启动事务，如果执行commit则提交事务。如果执行commit work and chain则提交事务并自动启动下一个事务。
1、事务隔离级别为读提交时，写数据只会锁住相应的行
2、事务隔离级别为可重复读时，如果检索条件有索引（包括主键索引）的时候，默认加锁方式是next-key 锁；如果检索条件没有索引，更新数据时 会锁住整张表。一个间隙被事务加了锁，其他事务是不能在这个间隙插入记录的，这样可以防止幻读。
3、事务隔离级别为串行化时，读写数据都会锁住整张表
4、隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。****
5、MYSQL MVCC实现机制参考链接：https://blog.csdn.net/whoamiyang/article/details/51901888****
6、关于****next-key 锁可以参考链接：https://blog.csdn.net/bigtree_3721/article/details/73731377********
