《Mysql技术内幕，Innodb存储引擎》——事物

事物

• 事物中的操作要么都成功要么都不做，这是事物的目的，也是事物模型与文件系统的重要特征之一。
• 扁平事物(Flat Transactions) 所有操作都处于同一层次，要么都做要么都执行要么都回滚，无法提交或回滚一部分。因为其模型简单而广泛使用。
• 带保存点的扁平事物(Flat Transaction with Savepoint) 与扁平事物相比其允许在执行过程中回滚到某一个较早的状态(savepoint)，保存点 用来记住事物当前的状态。保存点在事物内部是递增的，即使回滚过后。
• 链事物(Chained Transaction) 提交一个事物时，释放不需要的对象，将必要的对象隐式地传给下一个要开始的事物。也就是说提交事物和开始下一个事物合并成了一个原子操作。其回滚仅限于当前事物。
• 嵌套事物(Nested Transaction) 层次嵌套事物，可以看成一颗事务树。叶子节点是扁平事物，子事物既可以提交也可以回滚，树中任意一个事物的回滚将引起其所有子事物的回滚，因此子事物只保留了ACI而不具有D的特性。
• 分布式事物(Distributed Transaction) 分布式环境下运行的扁平事物。

事物的实现

redo

1. 基本概念

• 重做日志用于实现持久性，由redo log buffer和redo log file两部分组成。
• Innodb在commit时必须先将事物的所有redo log写入到redo log file进行持久化。
• 为了确保redo log的持久性，在每次将重做日志缓冲写入日志文件后将调用一次fsync(原因在于写入日志文件很多时候只是写入文件系统的缓存，调用fsync则直接写入了磁盘)。
• 为了提高commit的性能，也可以设置等待一个时间周期后再执行fsync，但很可能导致数据丢失。
• redo log是属于存储引擎层的日志，记录每个页的修改。而二进制日志则是数据库层的日志记录的是操作对应的SQL语句。

2. 日志结构

• redo log以512B的块(block)进行存储，称为重做日志块(redo log block)。
• 由于512B与磁盘扇区一样大，因此可以保证其写入的原子性，所以不需要double write来保证数据一致性。
• log block中包括lob block header、log block 和log block tailer三部分。
• log group(重做日志组)其中有多个重做日志文件，每个文件大小相同。
• 重做日志文件中存储的就是log buffer中保存的log block，因此物理存储也是以block管理。
• log buffer刷到文件规则：事物提交、log buffer中有一半的内存已经被使用和log checkpoint。
• 每个redo log file的前2KB不写入block，因为log group中第一个文件将写入一些信息。

3. LSN

• Log Sequence Number，日志序列号，递增。
• LSN表示重做日志写入的字节总量，checkpoint的位置，页数据的版本(Innodb检测是否需要恢复就是根据页的LSN与redo log中LSN对比)。
• innodb重启时都会尝试着恢复数据，恢复时只需要回复checkpoint开始的日志部分。

undo

1. 基本概念

• undo log是为事物回滚准备的，MVCC也依赖于undo log。
• undo存放在undo段中，undo段位于共享表空间。
• undo是逻辑日志，只是将数据库逻辑地恢复到事物前的样子，因此回滚后可能数据结构和页本身都不一样了。

2. 存储管理

• Innodb中有rollback segment，每个回滚段中记录1024个undo log segment，在undo log segment中进行undo页的申请。
• innodb 1.1之前只有一个rollback segment，1.1后支持最大128个，因此同时支持事物的限制为128*1024.
• 事物在写入undo log时同样会写入redo log(undo也是写入数据到页中)。
• 事物提交后不能马上删除undo log，因为可能MVCC在使用，因此将其放入一个链表中，删除与否由purge线程判断。
• undo log放入链表后，如果该页的使用空间小于3/4，则表示该页还可以被重用。
• undo log的列表是以记录的进行组织的，而undo log中存放不同事物的undo log，因此purge在回收时涉及磁盘的离散读取操作。
• insert undo log事物提交后可以直接删除。
• update undo log是对delete和update操作产生的undo log，需要支持MVCC因此不可以直接删除，需要purge线程判断。

pruge

• delete和update操作一般不直接删除原数据而是在聚集索引上标记该记录的delete flag。(只在聚集索引上标记，如果查询的数据可以通过覆盖索引获取那么不就能查询出已删除的数据？)
• innodb中有个history列表，它根据事物提交的顺序将undo log链接起来，先提交的事物总在尾端。
• purge先从history中找到第一个需要被清理的记录，清理后将对该undo log页所在的其他事物进行清理，如果还被别的事物占用则跳过。该页清理完成则继续从history中找下一个。
• innodb_purge_batch_size 设置每次purge清理的undo页数，如果值太大则会导致CPU和磁盘IO过于集中。
• 当history list长度达到限制后，其会延缓DML操作。

group commit

• group commit指一次fsync可以刷新确保多个事物日志被写入文件。
• 开启二进制日志后，为了保证存储引擎层中的事物和二进制日志的一致性，二者之间使用两阶段事物。
  1. 事物提交时Innodb进行prepare操作。
  2. mysql数据库上层写入二进制日志。
  3. Innodb将日志写入redo log file，先修改内存中事物对应的信息并将其写入日志缓冲，而后调用fsync。
• 为了保证二进制日志与Innodb事物提交顺序一致，使用prepare_commit_mutex 锁，这将导致group commit失效。
• 为了支持group commit Mysql5.6使用Binary Log Group Commit(BLGC)。
• 在Mysql数据库的上层进行提交时先按照顺序将其放入一个队列，第一个事物成为leader其余为follower，步骤如下：
  1. Flush阶段，将每个事物的二进制日志写入内存中。
  2. Sync阶段，将内存中二进制日志刷到磁盘，若队列含有多个事物则仅一次fsync完成日志刷入
  3. Commit阶段，leader根据顺序调用存储引擎层的事物提交。

分布式事物

• Innodb支持XA事物，在使用分布式事物时需要使用Serializable的隔离级别。使用两阶段提交。
• XA事物由资源管理器(Resource Managers)、事物管理器(Transaction Manager)和应用程序(Application Program)组成。