1、概念

1.1是什么

一个事务是一个连续的一组数据库操作,要么全部执行成功，要么全部不执行。

2.2可以解决的问题

原子性: 确保工作单元内的所有操作都成功完成，否则事务将被中止在故障点，和以前的操作将回滚到以前的状态。

一致性: 确保数据库正确地改变状态后，成功提交的事务。

隔离性: 使事务操作彼此独立的和透明的。

持久性: 确保提交的事务的结果或效果的系统出现故障的情况下仍然存在。

2、隔离级别

2.1读未提交

    事务中的修改,即使没有提交,对其它事务也是可见的. 脏读(Dirty Read).

2.2读已提交（更新）

一个事务开始时,只能"看见"已经提交的事务所做的修改. 这个级别有时候也叫不可重复读(nonrepeatable read).

2.3可重复读（插入）

该级别保证了同一事务中多次读取到的同样记录的结果是一致的. 但理论上,该事务级别还是无法解决另外一个幻读的问题(Phantom Read).

幻读:  当某个事务读取某个范围内的记录时,另外一个事务又在该范围内插入了新的记录.当之前的事务再次读取该范围时,会产生幻行.(Phantom Row).

mysql的可重复读的隔离级别解决了 "不可重复读" 和 “幻读” (mvcc)2个问题.

2.4串行化

    强制事务串行执行,避免了上面说到的 脏读,不可重复读,幻读 三个的问题.

3、实现原理

        原子性、稳定性和持久性是通过redo 和 undo 日志文件实现的，不管是redo还是undo文件都会有一个缓存我们称之为redo_buf和undo_buf。同样，数据库文件也会有缓存称之为data_buf。

        Undo Log

        Undo Log 是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用Undo Log来实现多版本并发控制(简称：MVCC)。

        事务的原子性(Atomicity) 事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在执行的过程中发生 了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。

        原理:  Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方 （这个存储数据备份的地方称为Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了 ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。除了可以保证事务的原子性，Undo Log也可以用来辅助完成事务的持久化。

      事务的持久性(Durability):  事务一旦完成，该事务对数据库所做的所有修改都会持久的保存到数据库中。为了保证持久性，数据库 系统会将修改后的数据完全的记录到持久的存储上。

        用Undo Log实现原子性和持久化的事务的简化过程 假设有A、B两个数据，值分别为1,2。 

             A.事务开始. 

             B.记录A=1到undo log. 

             C.修改A=3. 

             D.记录B=2到undo log.

             E.修改B=4.

             F.将undo log写到磁盘。

             G.将数据写到磁盘。

             H.事务提交

         这里有一个隐含的前提条件：‘数据都是先读到内存中，然后修改内存中的数据，最后将数据写回磁盘’。 之所以能同时保证原子性和持久化，是因为以下特点： 

     A. 更新数据前记录Undo log。

     B. 为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。

     C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃，undo log是完整的， 可以用来回滚事务。 

      D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。

    缺陷：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。如果能够将数据缓存一段时间，就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化，即Redo Log.

Redo Log- 原理 和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，只要将Redo Log持久化即可， 不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据 Redo Log的内容，将所有数据恢复到最新的状态。

     Undo + Redo事务的简化过程 假设有A、B两个数据，值分别为1,2. 

     A.事务开始.

     B.记录A=1到undo log. 

     C.修改A=3.

     D.记录A=3到redo log.

     E.记录B=2到undo log. 

     F.修改B=4. 

     G.记录B=4到redo log.

     H.将redo log写入磁盘。 

     I.事务提交

Undo + Redo事务的特点:

      A. 为了保证持久性，必须在事务提交前将Redo Log持久化。        

     B. 数据不需要在事务提交前写入磁盘，而是缓存在内存中。

     C. Redo Log 保证事务的持久性。

     D. Undo Log 保证事务的原子性。

     E. 有一个隐含的特点，数据必须要晚于redo log写入持久存储。

IO性能 Undo + Redo的设计主要考虑的是提升IO性能。虽说通过缓存数据，减少了写数据的IO. 但是却引入了新的IO，即写Redo Log的IO。如果Redo Log的IO性能不好，就不能起到提高性能的目的。 为了保证Redo Log能够有比较好的IO性能，InnoDB 的 Redo Log的设计有以下几个特点： A. 尽量保持Redo Log存储在一段连续的空间上。因此在系统第一次启动时就会将日志文件的空间完全分配。 以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。

         B. 批量写入日志。日志并不是直接写入文件，而是先写入redo log buffer.当需要将日志刷新到磁盘时 (如事务提交),将许多日志一起写入磁盘. 

        C. 并发的事务共享Redo Log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起， 以减少日志占用的空间。例如,Redo Log中的记录内容可能是这样的： 记录1:记录2:记录3:记录4:记录5: 

        D. 因为C的原因,当一个事务将Redo Log写入磁盘时，也会将其他未提交的事务的日志写入磁盘。

          E. Redo Log上只进行顺序追加的操作，当一个事务需要回滚时，它的Redo Log记录也不会从 Redo Log中删除掉。

4、mvcc

InnoDB的MVCC是通过在每行记录后面保存2个隐藏的列来实现的,一列保存了行的创建时间,一列保存了行的过期时间(或删除时间).但它们都存储的是系统版本号。

MVCC最大的作用是:  实现了非阻塞的读操作,写操作也只锁定了必要的行.解决了幻读的问题。

4.1概念

4.2原理

    .DATA_TRX_ID--标记了最新更新这条行记录的transaction id，每处理一个事务，其值自动+1

    .DATA_ROLL_PTR--指向当前记录项的rollback segment的undo log记录，找之前版本的数据就是通过这个指针

    .DB_ROW_ID--当由innodb自动产生聚集索引时，聚集索引包括这个DB_ROW_ID的值，否则聚集索引中不包括这个值.，这个用于索引当中

    .DELETE BIT位用于标识该记录是否被删除，这里的不是真正的删除数据，而是标志出来的删除。真正意义的删除是在commit的时候

select:  InnoDB会根据以下两个条件检查每行记录:

        a.InnoDB只会查找版本早于当前事务版本的数据行(也就是,行的系统版本号小于或等于事务的系统版本号)，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的.

        b.行的删除版本要么未定义,要么大于当前事务版本号,这可以确保事务读取到的行，在事务开始之前未被删除.

只有a,b同时满足的记录，才能返回作为查询结果.

update：

    begin->用排他锁锁定该行->记录undo log->新插入一行记录->记录redo log，写事务编号，回滚指针指向undo log中的修改前的行。

mvcc实现示例如下：

 https://blog.csdn.net/whoamiyang/article/details/51901888