InnoDB中的事务的隔离级别和实现

数据库的事务

1、概念

事务是对数据库操作的序列，这些序列是不能够被拆开来执行的，要么全部执行，要么全部不执行，是数据库一个状态到另外一个状态的转换。

2、特性介绍——ACID

A、原子性：该特性说明在某个事务执行的过程中，不可分割，要么全部执行，要么全部不执行。
B、一致性：
C、隔离性：该特性说明在各个事务并发执行期间，事务之间是互不影响的
D、持久性：该特性说明事务在提交过之后，对于数据库中数据的修改是永久的，不可回滚，不可更改。

3、事务的四种隔离级别

A、READ UNCOMMITED
B、READ COMMITED
C、REPEATABLE READ（InnoDB存储引擎默认的隔离级别）
D、SERIALIABLE

4、事务之间相互作用产生影响的种类

A、脏读：在当前执行的事务中，读取到了另外一个未提交事务正在处理的数据，而这一点违反了事务的隔离性，由于InnoDB存储引擎默认的隔离级别是REPEATABLE READ，所以，在一般的开发过程中，比较难以遇到这种情况。


可见，在READ UNCOMMITTED隔离级别之下，会话A的事务中能读取到会话B事务中未提交的数据。

B、不可重复度：在一个事务中，多次读到同一个数据集合，但是，在这期间，又有新的事务也访问了改数据集合，并且在其中做了一部分DML操作，这就导致，我这个事务两次读取到的数据是不一致的了，这种情况叫做不可重复读。而出现这种状态是数据库的隔离级别为READ COMMITED，所以，在使用过程中需要注意一下。


不可重复读与脏读的区别在于：脏读读取到的是未提交的数据，而不可重复读读到的是其他食物已经提交的数据。

幻读：是指在同一个事务中，连续执行两次相同的SQL语句，第二次查询的结果会返回之前不存在的数据行。而在READ COMMITTED隔离级别之下，会出现这种情况。
解决方案：由于InnoDB存储引擎中默认的事务隔离级别为REPEATABLE READ，所以，在该隔离界别下使用的是Next-Key Locking技术，而该技术使用的是间隙锁+Record Lock,所以，避免了该问题的出现。

5、事务的实现方式
在数据库进行修改时，不仅会产生redo log，还会产生undo log。

redo log

1、重做日志
分为重做日志缓存和重做日志文件，它主要保证了数据库的一致性，InnoDB是支持事务的存储引擎，它通过Force Log at Commit技术，保证了在每次事务提交之前，事务中的所有日志必须要写入重做日志文件中进行持久化，待事务的commit操作结束之后才算完成。
2、一致性问题的解决方案
为了能够确保在数据库宕机和操作系统宕机之后，数据库能够恢复之前的状态，操作系统需要定期的执行一次fsync操作将文件系统缓存中的日志刷新回磁盘
参数（innodb_flush_log_at_trx_commit）控制日志刷新的策略
0：在事务提交时，不进行重做日志写入操作，而是放在master thread中，每一秒钟会对重做日志文件进行一次fsync操作;
1：事务提交时，必须对重做日志文件进行一次fsync操作；
2：事务提交时，只是将重做日志写入文件系统缓存中，不进行fsync操作（如果操作系统不宕机，可能只会丢失文件系统缓存中的部分数据）

undo log

1、主要负责记录对于数据库的修改记录，方便事务进行回滚操作和多版本并发访问（MVCC），该日志的存储并非像redo log 一样，它有着自己的储存结构，存放在数据库中一个特殊的段（segment）中，这个段叫做undo 段，是放在共享表空间中。
2、MVCC：当一个事务读取某行数据是，发现该行数据被其他事务占有进行处理，这时就会通过undo log来查找该行数据之前的版本信息，来完成数据的获取。

根据事务理论同样可以将事务分为以下的几种

扁平事务

这是InnoDB存储引擎中，最常用的事务，也是相对来说，比较好理解的一种事务，主要的使用方式就是通过我们的事务操作语言（BEGIN WORK、ROLLBACK WORK、COMMIT WORK），但是这类事务在TPS较高的平台上相对来说，就比较难以应用了，因为回滚带来的性能上的差别太大了，如果事务中某一个环节抛出异常，就不得不终止这个事务了。而为了解决这个问题，出现了下面这种事务。

带有保存节点的扁平事务

除了继承了扁平事务的特性之外，还要求操作系统对于数据库的状态进行相应的保存（设立一个保存点），这样就不至于，操作执行失败，回滚整个事务。

链事务

同样是对于上面这种事务的改善，因为，带有保存节点的事务是易失的，不是持久的，所以，在操作系统发生宕机的情况下，会带来巨大的开销。
该事务是在事务执行结束，释放掉一些不必要的数据，而对于一些必要的处理上下文隐式的传递给下一个事务开始，可以理解为，上一个事务的结束和下一个事务的开始是一个原子操作。下一个事务能够看到上一个事务执行的结果。

嵌套事务

1） 嵌套事务是由多个事务组成的一棵树，子树可以是嵌套事务，也可以是扁平事务。
2）处在叶子节点的事务是扁平事务。根节点的事务是顶级事务。
3）子事务既可以提交也可以回滚，而提交之后不一定立即执行，除非它的父事务已经提交。任何子事务都需要在顶级事务提交之后操是真正的提交
4）任意事务的回滚都会引起他所有子事务的回滚，不具有事务隔离性一说。

分布式事务

1）分布式环境下运行的扁平事务，而在分布式事务中，InnoDB存储引擎使用的隔离级别为SERIALIABLE。
2）分布式事务支持不同数据库之间进行事务处理，只要该数据库支持XA事务
3）该事务采用的是二阶段提交（two-phase commit）
第一阶段：所有参与XA事务的节点都进行数据准备状态，同时告诉事务管理器，我为XA事务做好准备了。
第二阶段：事务管理器告诉资源管理器执行回滚还是提交，如果有任何一个节点不能显示提交，则所有节点事务全部回滚。