MySQL-14.MySQL事务日志
C-14.MySQL事务日志事务有4种特性：原子性，一致性，隔离性和长期性。那么事务的四种特性到底是基于什么机制实现呢？
[*]事务的隔离性由锁机制实现。
[*]事务的原子性，一致性和长期性由事务的redo日志和undo日志来保证。
[*]REDO LOG称为重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的长期性。
[*]UNDO LOG称为回滚日志，回滚行记载到某个特定版本，用来保证事务的原子性，一致性。
REDO和UNDO本质都可以视为一种恢复操作，但是：
[*]redo log：是存储引擎层(innodb)生成的日志，记载的是"物理级别"上页的修改操作，比如页号xxx，偏移量yyy写入了'zzz'数据。主要为了保证数据的可靠性。
[*]undo log: 是存储引擎层(innodb)生成的日志，记载的是"逻辑操作"日志，比如对某一行数据进行了INSERT语句操作，那么undo log就记载一条与之相反的DELETE操作。主要用于事务的回滚（undo log 记载的是每个操作的逆操作）和一致性非锁定读（undo log回滚行记载到某种特定的版本 -- MVCC 即多版本并发控制）。
1.redo日志
InnoDB存储引擎是以页为单位来管理存储空间的。在真正访问数据页之前，需要把在磁盘上的页缓存到内存中的Buffer Pool之后，才可以访问。所有的变更都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以一定的频率被刷入磁盘（checkPoint机制），通过缓冲池来优化CPU和磁盘之间的鸿沟，这样就可以保证团体的性能。
1.1 为什么需要REDO日志
一方面，缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟，checkpoint机制可以保证数据的终极写入到磁盘，然而由于checkpoint并不是每次变更的时候就触发的，而是master线程隔一段时间去处理的。所以最坏的环境就是事务提交后，刚写完缓冲池，数据库宕机了，那么这段数据就丢失了，无法恢复。
另一方面，事务包罗长期性的特性，就是说对于一个已经提交的事务，在事务提交后即使系统发生了崩溃，这个事务对数据库所作的更改也不会丢失。
那么如何保证这个长期性呢？一个简朴的做法：在事务提交完成之前把该事务所修改的所有页面都革新到磁盘，但是这个简朴的做法有问题。
[*]修改量与革新磁盘工作量严肃不成正比
有时候我们仅仅修改了某个页面中的一个字节，但是我们知道在InnoDB中是以页为单位来进行磁盘IO的，也就是说我们在该事务提交时不得不将一个完备的页面从内存中革新到磁盘，一个页面默认是16KB，只修改一个字节，就要革新16KB数据到磁盘上显然是太小题大作了。
[*]随机IO革新较慢
一个事务大概包罗很多语句，即使是一条语句也大概修改很多页面，假如该事务修改的这些页面大概并不相邻，这就意味着在将某个事务修改的Buffer Pool中的页面革新到磁盘时，需要进行很多的随机IO，随机IO比顺序IO要慢，尤其对于传统的机械硬盘来说。
另一个解决的思路：我们只是想让已经提交了的事务对数据库中数据所作的修改永久见效，即使厥后系统崩溃，在重启后也能把这种修改恢复出来。所以我们其实没有必要在每次事务提交时就把事务在内存中修改过的全部页面革新到磁盘，只需要把修改了那些东西记载一下就好。比如，某个事务将系统表空间中第10号页面中偏移量为100处的那个字节的值1改成2。我们只需要记载一下：将第0号表空间的10号页面的偏移量为100处的值更新为2。
InnoDB引擎的事务采用了WAL技能（Write-Ahead Logging），这种技能的思想就是先写日志，再写磁盘，只有日志写入成功，才算事务提交成功，这里的日志就是redo log。当发生宕机且数据未刷到磁盘的时候，可以通过redo log来恢复，保证ACID中的D，这就是redo log的作用。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623170833873-1740801908.jpg
1.2 REDO日志的好处，特点
1.好处
[*]redo日志降低了刷盘频率
[*]redo日志占用的空间非常小
存储表空间ID、页号、偏移量(可以简朴的明白，表空间ID + 页号 + 偏移量 就可以确定修改数据的某些列，这里我也不在往下搜索了。)以及需要更新的值，所需的存储空间是很小的，刷盘快。
2.特点
[*]redo日志是顺序写入磁盘的
在执行事务的过程中，每执行一条语句，就大概产生若干条redo日志，这些日志是按照产生的顺序写入磁盘的，也就是使用顺序IO，效率比随机IO快。
[*]事务执行过程中，redo log不停记载
redo log跟bin log的区别，redo log是存储引擎层产生的，而bin log是数据库层产生的。假设一个事务，对表做10万行的记载插入，在这个过程中，不停不停的往redo log顺序记载，而bin log不会记载，直到这个事务提交，才会一次写入到bin log文件中。
1.3 redo的构成
Redo log可以简朴的分为以下两个部分：
[*]重做日志的缓冲（redo log buffer），保存在内存中，是易失的。
在服务器启动时就向操作系统申请了一大片称之为redo log buffer的连续内存空间，翻译成中文就是redo日志缓冲区。这片内存空间被划分成若干个连续的redo log block。一个redo log block占用512字节大小。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623170847985-768987315.jpg
参数设置：innodb_log_buffer_size:
redo log buffer大小，默认16M，最大值是4096M，最小值为1M。
mysql> select @@global.innodb_log_buffer_size;#只是全局变量
+---------------------------------+
| @@global.innodb_log_buffer_size |
+---------------------------------+
| 16777216 |
+---------------------------------+
1 row in set (0.00 sec)
[*]重做日志文件（redo log file），保存在硬盘中，是长期的。在datadir变量，路径下，show variables like 'datadir'查看
REDO日志文件如图所示，此中的ib_logfile0和ib_logfile1即位REDO日志。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623170903460-1463028283.jpg
1.4 redo的团体流程
以一个更新事务为例，redo log流转过程，如下图所示：
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623170916737-1983711143.jpg
第1步：先将原始数据从磁盘中读入内存中来，修改数据拷贝到内存。
第2步：生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值。
第3步：当事务commit时，将redo log buffer中的内容刷新到redo log file，对redo log file采用追加写的方式。
第4步：定期将内存中修改的数据刷新到磁盘中。体会
Write-Ahead Log(预先日志长期化)：在长期化一个数据页之前，先将内存中相应的日志页长期化。
1.5 redo log的刷盘计谋
redo log的写入并不是直接写入磁盘的，InnoDB引擎会在写redo log的时候先写redo log buffer，之后以一定的频率刷入到真正的redo log file中。这里的一定频率怎么看待呢？这就是我们要说的刷盘计谋。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171009504-1566162726.jpg
注意，redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去，只是刷入到文件系统缓存（page cache）中去（这是现代操作系统为了提高文件写入效率做的一个优化），真正的写入会交给系统自己来决定（比如page cache足够大了）。那么对于InnoDB来说就存在一个问题，假如交给系统来同步，同样假如系统宕机，那么数据也丢失了（虽然整个系统宕机的概率照旧比力小的）。
针对这种环境，InnoDB给出innodb_flush_log_at_trx_commit参数，该参数控制 commit提交事务时，如何将 redo log buffer 中的日志革新到 redo log file 中。它支持三种计谋：
[*]设置为0：表示每次事务提交时不进行刷盘操作。（系统默认master thread每隔1s进行一次重做日志的同步）
[*]设置为1：表示每次事务提交时都将进行同步，刷盘操作（默认值）
[*]设置为2：表示每次事务提交时都只把 redo log buffer 内容写入 page cache，不进行同步。由os自己决定什么时候同步到磁盘文件。
mysql> select @@global.innodb_flush_log_at_trx_commit;#global变量
+-----------------------------------------+
| @@global.innodb_flush_log_at_trx_commit |
+-----------------------------------------+
| 1 |
+-----------------------------------------+
1 row in set (0.00 sec)除了后台线程每秒1次的轮询操作，另有一种环境，当redo log buffer占用的空间即将达到innodb_log_buffer_size（这个参数默认是16M）的一般的时候，后台线程会主动刷盘。
1.6 差别刷盘计谋演示
1.流程图
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171046432-1680469724.jpg
小结：innodb_flush_log_at_trx_commit=1
当1时，只要事务提交成功，redo log记载就一定在硬盘里，不会有任何数据丢失。
假如事务执行期间MySQL服务挂了或系统宕机了，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。可以保证ACID的D，数据绝对不会丢失，但是效率最差的。
建议使用默认值，虽然操作系统宕机的概率理论小于数据库宕机的概率，但是一般既然使用了事务，那么数据的安全相对来说更紧张些。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171142411-1755447723.jpg
小结innodb_flush_log_at_trx_commit=2
为2时，只要事务提交成功，redo log buffer 中的内容只写入文件系统缓存（page cache）。
假如仅仅只是MySQL挂了不会有任何数据丢失，但是操作系统宕机大概会有1秒数据的丢失，这种环境下无法满足ACID中的D。但是数据2肯定是效率最高的。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171218840-213333594.jpg
小结：innodb_flush_log_at_trx_commit=0
为0时，master thread中每1秒进行一次重做日志的fsync操作，因此实例crash最多丢失1秒钟内的事务。
（master thread是负责将缓冲池中的数据异步革新到磁盘，保证数据的一致性）
这种环境下，还大概出现事务未提交，就已经写入redo log buffer和redo file的大概性。
数据0的话，是一种折中的做法，它的IO效率理论是高于1的，低于2的，这种计谋也有丢失数据的风险，也无法保证D。
2.举例
#宋老师，举例代码，未执行，可能会出现时间不一致，正常情况。
#10-事务日志
USE atguigudb3;
CREATE TABLE test_load(
a INT,
b CHAR(80)
)ENGINE=INNODB;
#创建存储过程，用于向test_load中添加数据
DELIMITER//
CREATE PROCEDURE p_load(COUNT INT UNSIGNED)
BEGIN
DECLARE s INT UNSIGNED DEFAULT 1;
DECLARE c CHAR(80)DEFAULT REPEAT('a',80);
WHILE s<=COUNT DO
INSERT INTO test_load SELECT NULL,c;
COMMIT;
SET s=s+1;
END WHILE;
END //
DELIMITER;
#测试1：
#设置并查看：innodb_flush_log_at_trx_commit
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
#set GLOBAL innodb_flush_log_at_trx_commit = 1;
#调用存储过程
CALL p_load(30000); #1min 28sec
#测试2：
TRUNCATE TABLE test_load;
SELECT COUNT(*) FROM test_load;
SET GLOBAL innodb_flush_log_at_trx_commit = 0;
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
#调用存储过程
CALL p_load(30000); #37.945 sec
#测试3：
TRUNCATE TABLE test_load;
SELECT COUNT(*) FROM test_load;
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
#调用存储过程
CALL p_load(30000); #45.173 sec
[*]innodb_flush_log_at_trx_commit：控制 redo log 革新到磁盘的计谋，默认为1。
[*]innodb_log_file_size：单个 redo log 文件设置大小，默认值为 48M 。最大值为512G，注意最大值指的是整个 redo log 系列文件之和，即（innodb_log_files_in_group * innodb_log_file_size ）不能大于最大值512G。
mysql> show variables like 'innodb_log_files_in_group';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| innodb_log_files_in_group | 2 |
+---------------------------+-------+
1 row in set (0.00 sec)
#ib_logfile0
#ib_logfile1根据业务修改其大小，以便容纳较大的事务。编辑my.cnf文件并重启数据库见效，如下所示
mysql> show variables like 'innodb_log_file_size';
+----------------------+----------+
| Variable_name | Value |
+----------------------+----------+
| innodb_log_file_size | 50331648 |
+----------------------+----------+
1 row in set (0.00 sec)2.日志文件组
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171408074-650919376.jpg
统共的redo日志文件大小其实就是：innodb_log_file_size × innodb_log_files_in_group。
采用循环使用的方式向redo日志文件组里写数据的话，会导致后写入的redo日志覆盖掉前边写的redo日志？当然！所以InnoDB的设计者提出了checkpoint的概念。
3.checkpoint
在整个日志文件组中另有两个紧张的属性，分别是 write pos、chleckpoint
[*]write pos是当前记载的位置，一边写一边后移
[*]checkpoint是当前要擦除的位置，也是往后推移
每次刷盘 redo log记载到日志文件组中，write pos位置就会后移更新。每次MySQL加载日志文件组恢复数据时，会清空加载过的redo log记载，并把 checkpoint后移更新。write pos和checkpoint 之间的还空着的部分可以用来写入新的redo log记载。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171423030-1848574148.jpg
假如 write pos 追上 checkpoint ，表示日志文件组满了，这时候不能再写入新的 redo log记载，MySQL 得停下来，清空一些记载，把 checkpoint 推进一下。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171615845-1987395221.jpg
1.9 redo log 小结
InnoDB的更新操作采用的是Write Ahead Log (预先日志长期化)计谋，即先写日志，再写入磁盘。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171629682-580225148.jpg
2.Undo日志
redo log是事务长期性的保证，undo log是事务原子性的保证。在事务中更新数据的前置操作其实是要先写入一个undo log。
2.1 如何明白Undo日志
事务需要保证原子性，也就是事务中的操作要么全部完成，要么什么也不做。但有时候事务执行到一半会出现一些环境，比如：
[*]环境一：事务执行过程中大概碰到各种错误，比如MySQL服务器自己的错误，操作系统错误，甚至是突然断电导致的错误。
[*]环境二：程序员可以在事务执行过程中手动输入ROLLBACK语句竣事当前事务的执行。
以上环境出现，我们需要把数据改回原来的样子，这个过程称之为回滚，这样就可以造成一个假象：这个事务看起来什么都没做，所以符合原子性要求。
每当我们要对一条记载做改动时（这里的改动可以指INSERT、DELETE、UPDATE），都需要”留一手“ -- 把回滚时所需的东西记下来。比如：
[*]你插入一条记载时，至少要把这条记载的主键值记下来，之后回滚的时候只需要把这个主键值对应的记载删掉就好了。（对于每个INSERT，InnoDB存储引擎会完成一个DELETE）。
[*]你删除了一条记载，至少要把这条记载中的内容都记下来，这样之后回滚时再把这些内容构成的记载插入到表中就好了。（对于每个DELETE，InnoDB存储引擎会执行一个INSERT）。
[*]你修改了一条记载，至少要把修改这条记载前的旧值都记载下来，这样之后回滚时再把这条记载更新为旧值就好了。（对于每个UPDATE，InnoDB存储引擎会执行一个相反的UPDATE，将修改前的行放回去）。
MySQL把这些为了回滚而记载的这些内容称之为撤销日志或者回滚日志(即undo log)。注意，由于查询操作(SELECT)并不会修改任何用户记载，所以在查询操作执行时，并不需要记载相应的undo日志。
此外，undo log会产生redo log，也就是undo log的产生会陪同着redo log的产生，这是由于undo log也需要长期性的保护。
关于这句话，我的明白，在事务的过程中，为了保证数据修改的长期性，会有redo log的生成。为了保证数据可以或许实现逻辑上的回滚，注意此处，只是逻辑上的回滚，就好比，在一个事务中a和b，a向b转了100元，此时事务回滚的话，就是b向a转回100元。这实际上是两次update操作，第一次update操作是无法执行撤销的，只是b向a转回100元，是MySQL服务读取undo log日志，自动执行的，为了保证该语句，执行的长期性，也需要先写入redo log日志。但我觉得，undo log的回滚执行，会陪同着redo log的产生，更好明白。
注意，我只是记载条记，方便忘记时查看，假如条记不好明白，强烈建议看原视频。我觉得，本章节的知识，确实比力抽象，不是很好明白。
2.2 Undo日志的作用
[*]作用1：回滚数据
用户对undo日志大概有误解：undo用于将数据库物理地恢复到执行语句或事务之前的样子。但事实并非如此。undo是逻辑日志，只是将数据库逻辑地恢复到原来的样子。所有修改都被逻辑地取消了，但是数据结构和页自己在回滚之后大概大不相同。
这是由于在多用户并发系统中，大概会有数十，数百甚至数千个并发事务。数据库的主要使命就是协调对数据记载的并发访问。比如，一个事务在修改当前一个页中某几条记载，同时另有别的事务在对同一个页中另几条记载进行修改。因此，不能将一个页回滚事务开始的样子，由于这样会影响其他事务正在进行的工作。
[*]作用2：MVCC
undo的另一个作用是MVCC，即在InnoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记载时，若该记载已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。MVCC后续章节，会讲解。
2.3 undo的存储结构
1.回滚段与undo页
InnoDB对undo log的管理采用段的方式，也就是回滚段(rollback segment)。每个回滚段记载了1024个undo log segment，而在每个undo log segment段中进行undo页的申请。段是MySQL数据存储结构的一个，行 -> 页 -> 区 -> 段 -> 表空间，详细见第七章条记
[*]在InnoDB1.1版本之前（不包括1.1版本），只有一个rollback segment，因此支持同时在线的事务限制为1024。虽然对绝大多数的应用来说都已经够用。
[*]从1.1版本开始InnoDB支持最大128个rollback segment，故其支持同时在线的事务限制提高到了128*1024。
innodb_log_file_size=200M虽然InnoDB1.1版本支持了128个rollback segment，但是这些rollback segment都存储于共享表空间ibdata中，从InnoDB1.2版本开始，可通过参数对rollback segment做进一步的设置。这些参数包括：
[*]innodb_undo_directory：设置rollback segment文件所在的路径。这意味着rollback segment可以存放在共享表空间以外的位置，即可以设置为独立表空间。该参数的默认值为“”，表示当前InnoDB存储引擎的目录。
[*]innodb_undo_logs：设置rollback segment的个数，默认值为128。在InnoDB1.2版本中，该参数用来替换之前版本的参数innodb_rollback_segments。注意，在MySQL8.0.25版本下，innodb_undo_logs为空，innodb_rollback_segments正常使用。
[*]innodb_undo_tablespaces：设置构成rollback segment文件的数量，这样rollback segment可以较为平均地分布在多个文件中。设置该参数后，会在路径innodb_undo_directory看到undo为前缀的文件，该文件就代表rollback segment文件。
undo log相关参数一般很少改动。
undo页的重用
当我们开启一个事务需要写undo log的时候，就得先去undo log segment中去找到一个空闲的位置，当有空位的时候，就去申请undo页，在这个申请到的undo页中进行undo log的写入。我们知道mysql默认一页的大小是16k。
为每一个事务分配一个页，是非常浪费的(除非你的事务非常长)，假设你的应用的TPS(每秒处理的事务数目)为1000，那么1s就需要100o个页，大概需要16M的存储，1分钟大概需要1c的存储。假如照这样下去除非MySQL清算的非常勤快，否则随着时间的推移，磁盘空间会增长的非常快，而且很多空间都是浪费的。
于是undo页就被设计的可以重用了，当事务提交时，并不会立刻删除undo页。由于重用，所以这个undo页大概稠浊着其他事务的undo log。undo log在commit后，会被放到一个链表中，然后判断undo页的使用空间是否小于3/4，假如小于3/4的话，则表示当前的undo页可以被重用，那么它就不会被回收，其他事务的undo log可以记载在当前undo页的背面。由于undo log是离散的，所以清算对应的磁盘空间时，效率不高。
2.回滚段与事务
1.每个事务只会使用一个回滚段，一个回滚段在同一时候大概会服务于多个事务。
2当一个事务开始的时候，会订定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数据会被复制到回滚段。
3．在回滚段中，事务会不停填充盘区，直到事务竣事或所有的空间被用完。假如当前的盘区不够用，事务会在段中哀求扩展下一个盘区，假如所有已分配的盘区都被用完，事务会覆盖最初的盘区或者在回滚段允许的环境下扩展新的盘区来使用。
4.回滚段存在于undo表空阐中，在数据库中可以存在多个undo表空间，但同一时候只能使用一个undo表空
间。
mysql> show variables like 'innodb_rollback_segments';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| innodb_rollback_segments | 128 |
+--------------------------+-------+
1 row in set (0.00 sec)5.当事务提交时，InnoDB存储引擎会做以下两件事情:
[*]将undo log放入列表中，以供之后的purge操作
[*]判断undo log所在的页是否可以重用，若可以分配给下个事务使用
3.回滚段中的数据分类
1.未提交的回滚数据(uncommitted undo information)：该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其他事务的数据覆盖。
2.已经提交但未逾期的回滚数据(committed undo information)：该数据关联的事务已经undo retention参数的保持时间的影响。
3.事务已经提交并逾期的数据( expired undo information)：事务已经提交，而且数据保存Eundo retention参数指定的时间，属于已经逾期的数据，当回滚段满了之后，会优先覆盖事务已经提交并逾期的数据。
事务提交后并不能马上删除undo log及undo log所在的页。这是由于大概另有其他事务需要通过undo log记载之前的版本。故事提交时将undo log放入一个链表中，是否可以终极删除undo log及undo log所在页由purge线程来判断。
2.4 undo的类型
在InnoDB存储引擎中，undo log分为：
[*]insert undo log
insert undo log是指在insert操作中产生的undo log。由于insert操作的记载，只对事务自己可见，对其他事务不可见（这是事务隔离性的要求），故该undo log可以在事务提交后直接删除。不需要purge操作。
我结合上一章条记，对于本句话的明白：由于MySQL所有的隔离级别中，都制止了脏写问题，(脏写，也就是，一个事务读取到了另一个事务未提交的数据的修改，并对之重新修改)。也就是说，一个事务中，不能读取到其他事务中最新的内容的修改，只能读取到undo log暂存中的内容，也就是修改前的数据。而本次事务新增的内容，自然在undo log中，没有修改前的数据，所以因本次insert操作产生的undo log，在本次事务提交后，也就无需保存。
[*]update undo log
update undo log记载的是delete和update操作产生的undo log。该undo log大概需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。这个不是很明白，等学到MVCC章节后，在来答复。
2.5 undo log的生命周期
1.简要生成过程
以下是undo + redo事务的简化过程
假设有2个数值，分别为A=1和B=2，然后将A修改为3，B修改为4
mysql> show variables like 'innodb_undo_tablespaces';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| innodb_undo_tablespaces | 2 |
+-------------------------+-------+
1 row in set (0.00 sec)
#undo log的数量,最少为2，undo log的truncate(截断，类似于删除)操作有purge(清除)协调线程发起。在truncate某个undo log表空间的过程中，保证有一个可用的undo log可用。
[*]在1-8步骤的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。
[*]假如在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，由于此时redo log已经长期化。
[*]若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。
只有Buffer Pool的流程
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171652142-2129719964.jpg
有了Redo Log和Undo Log之后：
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171703528-1753025519.jpg
在更新Buffer Pool中的数据之前，我们需要先将该数据事务开始之前的状态写入Undo Log中。假设更新到一半堕落了，我们就可以通过Undo Log来回滚到事务开始前。
2.详细生成过程
对于InnoDB引擎来说，每个行记载除了记载自己的数据之外，另有几个隐藏的列:
[*]DB_ROW_ID：假如没有为表显式的定义主键，并且表中也没有定义唯一索引，那么InnoDB会自动为表添加一个row_id的隐藏列作为主键。
[*]DB_TRX_ID：每个事务都会分配一个事务ID，当对某条记载发生变更时，就会将这个事务的事务ID写入trx_id中。
[*]DB_ROLL_PTR：回滚指针，本质上就是指向undo log的指针。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171716750-1661026063.jpg
当我们执行INSERT时：
1.start transaction;
2.记录A=1到undo log;
3. update A = 3;
4.记录A=3 到redo log;
5.记录B=2到undo log;
6. update B = 4;
7.记录B = 4到redo log;
8．将redo log刷新到磁盘
9. commit插入的数据都会生成一条insert undo log，并且数据的回滚指针会指向它。undo log会记载undo log的序号、插入主键的列和值...，那么在进行rollback的时候，通过主键直接把对应的数据删除即可。
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171733381-627619401.jpg
当我们执行UPDATE时：
begin;
INSERT INTO user (name) VALUES ("tom");https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171744127-788680095.jpg
这时会把老的记载写入新的undo log，让回滚指针指向新的undo log，它的undo no是1，并且新的undo log会指向老的undo log (undo no=0)。
假设现在执行:
UPDATE user SET name = 'Sun' WHERE id=1;https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171757968-1772382930.jpg
对于更新主键的操作，会先把原来的数据deletemark标识打开，这时并没有真正的删除数据，真正的删除会交给清算线程去判断，然后在背面插入一条新的数据，新的数据也会产生undo log，并且undo log的序号会递增。可以发现每次对数据的变更都会产生一个undo log，当一条记载被变更多次时，那么就会产生多条undo log,undo log记载的是变更前的日志，并且每个undo log的序号是递增的，那么当要回滚的时候，按照序号依次向前推，就可以找到我们的原始数据了。
3.undo log是如何回滚的
以上面的例子来说，假设执行rollback，那么对应的流程应该是这样：
[*]通过undo no=3的日志把id=2的数据删除
[*]通过undo no=2的日志把id=1的数据的deletemark还原成0
[*]通过undo no=1的日志把id=1的数据的name还原成Tom
[*]通过undo no=0的日志把id=1的数据删除
4.undo log的删除
[*]针对于insert undo log
由于insert操作的记载，只对事务自己可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作。
[*]针对于update undo log
该undo log大概需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。
补充:
purge线程两个主要作用是：清算undo页和清除page里面带有Delete_Bit标识的数据行。在InnoDB中，事务中的Delete操作实际上并不是真正的删撤除数据行，而是一种Delete Mark操作，在记载上标识Delete_Bit，而不删除记载。是一种"假删除";只是做了个标记，真正的删除工作需要后台purge线程去完成。
2.6 小结
https://img2024.cnblogs.com/blog/2883613/202406/2883613-20240623171629682-580225148.jpg
undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。
redo log是物理日志，记载的是数据页的物理变化，undo log不是redo log的逆过程。
只是为了记载自己的学习历程，且本人程度有限，不对之处，请指正。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]