MySQL事务日志
💡
-
事务的隔离性由
锁机制实现。 -
事务的原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证：
- REDO LOG 称为 重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。
- UNDO LOG 称为 回滚日志 ，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。
有的DBA或许会认为 UNDO 是 REDO 的逆过程，其实不然。REDO 和 UNDO都可以视为是一种 恢复操作，但是：
- redo log: 是存储引擎层 (innodb) 生成的日志，记录的是**
"物理级别"**上的页修改操作，比如页号xxx，偏移量yyy写入了'zzz'数据。主要为了保证数据的可靠性。 - undo log: 是存储引擎层 (innodb) 生成的日志，记录的是
逻辑操作日志，比如对某一行数据进行了INSERT语句操作，那么undo log就记录一条与之相反的DELETE操作。主要用于事务的回滚(undo log 记录的是每个修改操作的逆操作) 和一致性非锁定读(undo log 回滚行记录到某种特定的版本——MVCC，即多版本并发控制)。
redo log
💡 InnoDB存储引擎是以**`页为单位`**来管理存储空间的。在真正访问页面之前，需要把在**`磁盘上`**的页缓存到内存中的**`Buffer Pool`**之后才可以访问。所有的变更都必须**`先更新缓冲池`**中的数据，然后缓冲池中的**`脏页`**会以一定的频率被刷入磁盘 (** `checkPoint`**机制)，通过缓冲池来优化CPU和磁盘之间的鸿沟，这样就可以保证整体的性能不会下降太快。
InnoDB引擎的事务采用了WAL技术 (Write-Ahead Logging)，这种技术的思想就是先写日志，再写磁盘，只有日志写入成功，才算事务提交成功，这里的日志就是redo log。当发生宕机且数据未刷到磁盘的时候，可以通过redo log来恢复，保证ACID中的D，这就是redo log的作用。
redo log的好处特点
💡 **好处**
- redo日志降低了刷盘频率
- redo日志占用的空间非常小
存储表空间ID、页号、偏移量以及需要更新的值，所需的存储空间是很小的，刷盘快。
特点
-
redo日志是顺序写入磁盘的
在执行事务的过程中，每执行一条语句，就可能产生若干条redo日志，这些日志是按照**
产生的顺序写入磁盘的**，也就是使用顺序ID，效率比随机IO快。 -
事务执行过程中，redo log不断记录
redo log 与 bin log的区别
💡
- redo log是**
存储引擎层产生的，而bin log是数据库层**产生的。 - redo log是顺序记录，事务不断执行，redo log不断执行；bin log是在事务提交后一次性写入。
- redo log主要用来保证持久性，bin log用来保证数据备份，主从同步等。
redo log 的整体流程
💡
redo log 刷盘策略
💡 InnoDB给出 **`innodb_flush_log_at_trx_commit`** 参数，该参数控制 commit提交事务 时，如何将 redo log buffer 中的日志刷新到 redo log file 中。它支持三种策略：
- 0：表示每次事务提交时不会主动将redo日志写入磁盘，只是依靠
master线程每隔1s将日志刷入redo log file中然后将其刷入磁盘。 - 1：默认策略，表示每次事务提交时都会把
redo日志同步到redo log file中并将其刷入磁盘。 - 2：表示每次事务提交时都只是把
redo日志同步到redo log file中，但并不会刷入磁盘，而是依靠操作系统的page cache刷入，默认1s。
checkpoint
在整个日志文件组中还有两个重要的属性，分别是 write pos、checkpoint
- **
write pos**是当前记录的位置，一边写一边后移 - **
checkpoint**是当前要擦除的位置，也是往后推移
每次刷盘 redo log 记录到日志文件组中，write pos 位置就会后移更新。每次MySQL加载日志文件组恢复数据时，会清空加载过的 redo log 记录，并把check point后移更新。write pos 和 checkpoint 之间的还空着的部分可以用来写入新的 redo log 记录。
如果 write pos 追上 checkpoint ，表示**日志文件组**满了，这时候不能再写入新的 redo log记录，MySQL 得 停下来，清空一些记录，把 checkpoint 推进一下。
undo log
💡 undo log是事务原子性的保证。在事务中 **`更新数据`** 的 **`前置操作`** 其实是要先写入一个 **`undo log`** 。
undo log日志的作用
💡 作用一：回滚数据。 作用二：undo的另一个作用是`MVCC`，即在InnoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录以及被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。
undo的存储结构
💡 InnoDB对undo log的管理采用段的方式，也就是 **`回滚段（rollback segment）`** 。每个回滚段记录了 **`1024`** 个 **`undo log segment`** ，而在每个undo log segment段中进行 **`undo页`** 的申请。 **undo页是可重用的。**
回滚段中的数据分类
💡
未提交的回滚数据(uncommitted undo information) ：该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其他事务的数据覆盖。已经提交但未过期的回滚数据(committed undo information) ：该数据关联的事务已经提交，但是仍受到undo retention参数的保持时间的影响。事务已经提交并过期的数据(expired undo information) ：事务已经提交，而且数据保存时间已经超过 undo retention参数指定的时间，属于已经过期的数据。当回滚段满了之后，就优先覆盖“事务已经提交并过期的数据"。事务提交后不能马上删除undo log及undo log所在的页。这是因为可能还有其他事务需要通过undo log来得到行记录之前的版本。故事务提交时将undo log放入一个链表中，是否可以最终删除undo log以undo log所在页由purge线程来判断。
undo的类型
💡
在InnoDB存储引擎中，undo log分为：
-
insert undo log
insert undo log是指insert操作中产生的undo log。因为insert操作的记录，只对事务本身可见，对其他事务不可见（这是事务隔离性的要求），故该undo log可以在事务提交后直接删除。不需要进行purge操作。
-
update undo log
update undo log记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。
undo流程
undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。
redo log是物理日志，记录的是数据页的物理变化，undo log不是redo log的逆过程
