mysql-innodb-事务

1. 事务概述

• 事务执行中要么都修改，要么都不修改，这是事务模型与文件系统重要区别之一。

• innodb引擎都事务彻底符合ACID特征：

  1. 原子性（Atomicity，或称不可分割性）

     • 事务中的全部操做均为一个总体，要么所有成功，要么有一条执行失败后回滚到事务前的状态。经过redo log实现。

  2. 一致性（Consistency）

     • 事务是一致性的单位，若是事务中某个动做失败了，系统能够撤销事务，返回初始状态。经过undo log实现。
     • 例如表中name字段是惟一约束，事务提交后或发生回滚后，name变得不惟一了，这就是破坏了一致性要求。

  3. 隔离性（Isolation）

     • 隔离性要求每一个读写事务的对象对其余事务对操做对象都是相互分离的，一般用锁来实现。
     • 经过各类锁来配合实现不一样级别都隔离性。例如行锁，间隙锁等。

  4. 持久性（Durability）

     • 事务一旦commit成功，结果就是永久性的。即便发生宕机也能将数据恢复。但外部缘由除外。是经过redo log来实现的。

2. 事务分类

扁平事务

• 全部事务处于同一层次。其操做都是原子性，要不所有成功，要不所有失败。

带有保存点的扁平事务

• 除了支持扁平事务支持的操做外，为事务几个过程设置保存点，容许回滚到事务中较早的某个节点。
• 对于扁平事务来讲，其隐式设置了一个起始保存点。所以只能回滚到事务开始时的状态。
• 保存点用SAVE WORK函数创建，保存点在事务内部是递增的，根据应用逻辑选择回到哪一个保存点。

链事务

• 保存点是非持久化都，当系统崩溃时，全部保存点都将消失，当进行恢复时，事务须要从新开始执行。
• 链事务思想：T1事务提交时，把必要处理都上下文隐式传给T2事务，以此类推。这意味着下一个事务能看到上一个事务的执行结果。
• 链事务只能保证回滚到最近的一个保存点。

嵌套事务

• 由若干事务组成一颗事务树，子树能够是嵌套事务也能够是扁平事务。
• 处于根节点的是顶层事务， 一个顶层事务控制着各个层次的子事务。
• 处在叶子节点的是扁平事务，每一个子事务的从根到叶子节点的距离能够不一样。
• 子事务能够commit或rollback，可是commit并不是当即生效，除非父事务已经commit，故任何子事务都在顶层事务提交完毕后才真正提交。
• 树的任意一个事务回滚会致使它全部的子事务一块儿回滚。故子事务仅保留ACI特性，不具有D特性。
• 在Moss理论中，只有叶子节点的事务才能完成访问数据库，发送消息等操做。高层事务仅负责逻辑调度控制，决定什么时候调用相关等子业务。

分布式事务

• 一般是在一个分布式环境下运行的扁平事务。

3. 事务实现

概述：事务的隔离行是由锁来实现的。原子性，一致性和持久性是经过redo log和undo log实现的。redo log称为重作日志。用来保证事务的原子性和持久性。undo log用来保证事务的一致性。redo是物理日志，记录的是页的物理修改。undo是逻辑日志，根据每行记录进行记录，能够回滚行记录到某个版本。

3.1 redo

1. 概述

   • 重作日志用来实现事务的持久性，由两部分组成，一个是内存中的重作日志缓冲（redo log buffer），另外一个是重作日志文件（redo log file）这是持久性的。redo log基本上都是顺序写的，数据库运行时不须要进行读取操做。

2. 与binlog比较

   1. 产生层面

      • binlog产生于mysql数据库上层，不针对innodb引擎。
      • redolog产生于innodb引擎层，是innodb特有的日志。

   2. 内容形式

      • binlog是一种逻辑日志，记录的的是对应的sql语句。
      • redolog是物理格式的日志，记录的是对每一个页的修改。

   3. sync时间点

      • binlog只在事务commit完成后写入一次。
      • redolog在事务进行中不断被写入。

3. log block

   • 概述：innodb中，redolog都是以512字节进行存储的。这意味着redo log buffer和redo log file都是以块(block)进行存储的。因为重作日志块大小和磁盘山区都是512字节，因此写入都是原子性的，不须要double write技术。

4. LSN

   1. 概述：LSN（Log Sequence Number）表明的是日志序列号。在innodb引擎中LSN占8个字节，而且单调递增。

   2. 含义：

      1. 重作日志的写入总量，单位为字节

         • 例如LSN数值为1000，T1写入100字节，则变为1100，T2写入200字节则变为1300，以此类推，表明着redolog的写入总量。

      2. checkpoint的位置

         • 经过单调增的LSN做为版本号来判断checkpoint点。

      3. 页的版本

         • LSN不只存在于redolog中，也存在于每一个页的头部，页头部的FIL_PAGE_LSN值记录了该页的LSN，在页中LSN表示该页最后刷新时的LSN大小。能够经过LSN判断页是否须要进行恢复操做。

5. 恢复

   • 概述：innodb引擎不管上次数据库是否正常关闭，都是尝试进行恢复，因为checkpoint已经刷新到磁盘页上到LSN，所以恢复过程当中，只须要恢复checkpoint开始到日志部分。

3.2 undo

1. 做用：

   1. undo为事务回滚提供支持，存放于数据库内部的一个特殊段(segment)内，这个段称为undo段，位于表共享空间内。undo是逻辑日志，所以只是将数据逻辑的恢复到原来到样子，全部修改都被逻辑地取消了。例如对于每个insert，innodb引擎会完成一个delete，对于每一个update也有相反的update。
   2. undolog为mvcc做数据支持，当用户读到一行被事务占用的记录时，能够经过undolog实现非锁定读取。
   3. undolog也会产生redolog，undolog也须要持久性保护。

2. undo 存储管理

   • innodb引擎有rollback segment，每一个回滚段记录了1024个undolog segment，undo页在undolog segment里申请。
   • 事务提交时，将undo log放入列表中，以供purge操做。同时判断undo log的页是否能够重用，若是能够分配给下个事务使用。
   • 事务提交后并不会立刻删除undo log及所在的页，由于其余事务可能须要经过undo log页拿到行记录以前的版本，是否能够删除须要purge线程来判断。
   • 若为每个事务都分配一个undo页，空间浪费严重，故undo页是能够重用的，有可能出现一个undo页里存储不一样事务的undo log，故purge操做须要涉及磁盘的离散读，是一个缓慢的过程。

3. undo log 格式

   1. insert undo log格式

      • insert undo log记录的是全部插入数据，由于insert操做的记录只对本事务可见，故在事务commit后不须要purge操做，直接删除。

   2. update undo log格式

      • update undo log记录的是delete和update操做的数据，该undolog可能须要提供对mvcc的支持，提交时放入undolog链表，等待purge线程删除。

3.3 purge

• purge用于完成delete和update中delete的最终操做。

3.4 group commit

1. 概念

   • 若事务为非只读事务，则每次事务提交都须要一次fsync操做，所以保证重作日志都写入磁盘。为了提升fsync性能，数据库提供了group commit功能，即一次刷新确保多个事务日志写入文件。

2. BLGC Binary Log Group Commit

   • 开启binlog后，为了保证引擎层的事务和二进制文件的一致性，两者之间使用了二阶段事务。BLGC使用了一种leader-follower的方式，将事务提交氛围Flush，Sync，Commit三个过程。

4. XA事务

5. 事务控制语句

6. 事务隔离级别

7. 分布式事务