事务的实现
redo log保证事务的持久性，undo log用来帮助事务回滚及MVCC的功能。
InnoDB存储引擎体系结构
redo log
Write Ahead Log策略
事务提交时，先写重做日志再修改页；当由于发生宕机而导致数据丢失时，就可以通过重做日志来完成数据的恢复。
- InnoDB首先将重做日志信息先放到重做日志缓存
- 按一定频率刷新到重做日志文件
重做日志文件： 在默认情况，InnoDB存储引擎的数据目录下会有两个名为ib_logfile1和ib_logfile2的文件。每个InnoDB存储引擎至少有1个重做日志文件组(group)，每个文件组下至少有2个重做日志文件。
下面图一，很好说明重做日志组以循环写入方式运行，InnoDB存储引擎先写ib_logfile1，当达到文件最后时，会切换至重做日志文件ib_logfile2.
而图2，增加一个OS Buffer，有助于理解fsync过程。
关于log group，称为重做日志组，是一个逻辑上的概念。InnoDB存储引擎实际只有一个log group。
log group中第一个redo log file，其前2KB部分保存4个512字节大小块：
重做日志缓冲刷新到磁盘
下面三种情况刷新：
- Master Thread每一秒将重做日志缓冲刷新到重做日志文件
- 每个事务提交时会将重做日志缓冲刷新到重做日志文件
- 当重做日志缓冲池剩余空间小于1/2时，重做日志刷新到重做日志文件
补充上述三种情况第二种，触发写磁盘过程由参数innodb_flush_log_at_trx_commit控制，表示提交(commit)操作时，处理重做日志的方式。
参数innodb_flush_log_at_trx_commit有效值有0、1、2
- 0表示当提交事务时，并不将事务的重做日志写入磁盘上日志文件，而是等待主线程每秒刷新。
- 1表示在执行commit时将重做日志缓冲同步写到磁盘，即伴有fsync的调用
- 2表示将重做日志异步写到磁盘，即写到文件系统的缓存中。不保证commit时肯定会写入重做日志文件。
0，当数据库发生宕机时，部分日志未刷新到磁盘，因此会丢失最后一段时间的事务。
2，当操作系统宕机时，重启数据库后会丢失未从文件系统缓存刷新到重做日志文件那部分事务。
下图有助于理解
重做日志块
在InnoDB存储引擎中，重做日志都是以512字节进行存储的。意味着重做日志缓存、重做日志文件都是以块(block)的方式进行保存的，每块512字节。
重做日志头12字节，重做日志尾8字节，故每个重做日志块实际可以存储492字节。
重做日志格式
redo log是基于页的格式来记录的。默认情况下，innodb的页大小是16KB(由 innodb_page_size变量控制)，一个页内可以存放非常多的log block(每个512字节)，而log block中记录的又是数据页的变化。
log body的格式分为4部分：
- redo_log_type：占用1个字节，表示redo log的日志类型。
- space：表示表空间的ID，采用压缩的方式后，占用的空间可能小于4字节。
- page_no：表示页的偏移量，同样是压缩过的。
- redo_log_body表示每个重做日志的数据部分，恢复时会调用相应的函数进行解析。例如insert语句和delete语句写入redo log的内容是不一样的。
如下图，分别是insert和delete大致的记录方式。
redo日志恢复
下面LSN(Log Sequence Number)代表checkpoint，当数据库在LSN为10000时发生宕机，恢复操作仅恢复LSN10000-LSN13000范围内日志
undo log
undo log的作用
undo是逻辑日志，只是将数据库逻辑地恢复到原来的样子；所有修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能不大相同。
undo log有两个作用：提供回滚和多个行版本控制(MVCC)。
InnoDB存储引擎回滚时，对于每个INSERT，会完成一个DELETE；对于每个DELETE，会执行一个INSERT；对于每个UPDATE，会执行一个相反的UPDATE，将修改前的行放回去。
MVCC： 当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。
undo log的存储方式
innodb存储引擎对undo的管理采用段的方式。rollback segment称为回滚段，每个回滚段中有1024个undo log segment。
在以前老版本，只支持1个rollback segment，这样就只能记录1024个undo log segment。后来MySQL5.5可以支持128个rollback segment，即支持128*1024个undo操作，还可以通过变量 innodb_undo_logs (5.6版本以前该变量是 innodb_rollback_segments )自定义多少个rollback segment，默认值为128。
undo log默认存放在共享表空间中。
事务提交undo log处理过程
当事务提交时，InnoDB存储引擎会做以下两件事：
- 将undo log放入一个列表中，以供之后的purge使用，是否可以最终删除undo log及所在页由purge线程来判断
- 判断undo log 所在的页是否可以重用，若可以，分配给下个事务使用
当事务提交时，首先将undo log放入链表中，然后判断undo页的使用空间是否小于3/4，若是，则表示该undo页可以被重用，之后新的undo log记录在当前undo log的后面
undo log分为：
- insert undo log
- update undo log
因为事务隔离性，insert undo log对其他事务不可见，所以该undo log可以在事务提交后直接删除，不需要进行purge操作。
update undo log记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能提交时就进行删除
update分为两种情况：
- date的列如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。
- update主键的操作可以分为两步：
- 首先将原主键记录标记为已删除，因此需要产生一个类型为TRX_UNDO_DEL_MARK_REC的undo log
- 之后插入一条新的记录，产生一个类型为TRX_UNDO_INSERT_MARK_REC的undo log
InnoDB purge时，会先从history列表找undo log，然后再从undo page中找undo log；可以避免大量随机读取操作，从而提高purge效率。
MVCC(多版本并发控制)
MVCC其实就是在每一行记录后面增加两个隐藏列，记录创建版本号和删除版本号，而每一个事务在启动的时候，都有一个唯一的递增的版本号。
MVCC只在REPEATABLE READ 和READ COMMITTED两个隔离级别下工作。读未提交不存在版本问题，序列化则对所有读取行加锁。
示例：
插入操作：记录的创建版本号就是事务版本号
如插入一条记录，事务id假设是1，则创建版本号也是1
| 若事务为非只读事务，则每次事务提交时需要进行一次fsync操作，以此保证重做日志都已经写入磁盘。但磁盘fsync性能有限，为提高磁盘fsync效率，当前数据库都提供group commit功能，即一次可以刷新确保多个事务日志被写入文件。
其中在保证MySQL数据库上层二进制文件的写入顺序，和InnoDB事务提交顺序一致，MySQL内部使用了prepare_commit_mutex锁，从而步骤3）中a）步不可以在其他事务执行步骤b）时进行，从而导致roup commit功能失效。
到此这篇关于MySQL系列之redo log、undo log和binlog详解的文章就介绍到这了,更多相关mysql redo log、undo log和binlog内容请搜索社区以前的文章或继续浏览下面的相关文章希望大家以后多多支持社区！
转播
