- 工信部备案号 滇ICP备05000110号-1
- 滇公安备案 滇53010302000111
- 增值电信业务经营许可证 B1.B2-20181647、滇B1.B2-20190004
- 云南互联网协会理事单位
- 安全联盟认证网站身份V标记
- 域名注册服务机构许可：滇D3-20230001
- 代理域名注册服务机构：新网数码
欢迎来到蓝队云小课堂，今天我们要一起探索数据库的神秘世界，揭开MySQL事务日志的神秘面纱。想象一下，你正在处理一笔重要的财务交易，突然电脑崩溃了，所有的数据都消失了。这听起来多么可怕！幸运的是，MySQL的事务日志就是我们的救星，它们确保即使在最糟糕的情况下，我们的数据也能安然无恙。
在数据库的世界里，事务是确保数据完整性的基石。而Undo Log和Redo Log就是事务的守护者，它们分别保障了事务的原子性和持久性。让我们一起来深入了解这两个英雄的职责和工作原理。
一、Undo Log
Undo Log是回滚日志，它的作用是在事务发生异常或主动回滚时，用于撤销已执行的操作，确保数据库数据能够回到事务开始前的状态，保证事务的原子性。
1. 工作原理
作用：Undo Log 记录了在事务执行过程中对数据的每次修改前的数据副本（即修改前的旧值），这些旧值在回滚时用于恢复到数据的原始状态。
事务开始时：事务执行过程中，每当进行写操作（如 INSERT、UPDATE、DELETE）时，数据库会将修改前的记录保存在 Undo Log 中。
回滚时：如果事务回滚，系统会通过 Undo Log 将这些记录回滚至修改之前的状态，从而实现撤销操作。
例如：
如果执行了一条 UPDATE 操作，事务会记录修改前的数据值。
如果事务最终失败或主动执行了回滚（ROLLBACK），数据库会使用 Undo Log 将被更新的数据恢复到原始值。
2. Undo Log的实现
逻辑日志：Undo Log 是一种逻辑日志，记录的是逻辑上的修改操作。它并不会直接记录每次操作的物理存储修改，而是记录修改前的数据。
链表结构：InnoDB 存储引擎会为每条记录维护一条 Undo Log 记录，并以链表的方式串联起来。如果事务需要回滚，MySQL 会沿着 Undo Log 链表进行逐条回滚，直到恢复到事务开始时的状态。
Undo Log 的类型：
对于 INSERT 操作，Undo Log 记录的是“删除”操作，因为如果事务回滚，需要撤销插入的数据。
对于 DELETE 操作，Undo Log 记录的是“插入”操作，用来恢复被删除的数据。
对于 UPDATE 操作，Undo Log 记录的是修改前的旧值，用来恢复原来的值。
3. 使用场景
事务回滚：当事务执行失败或用户显式要求回滚时，Undo Log 会将所有修改的数据恢复到事务开始前的状态。
MVCC（多版本并发控制）：Undo Log 也用于实现 MVCC 机制。不同事务可能在不同时间看到不同版本的数据，这些版本的数据就是由 Undo Log 提供的。这样，未提交的事务修改对其他事务是不可见的，帮助实现隔离性。
4. 示例
假设有一条 UPDATE 语句：UPDATE user SET balance = balance + 100 WHERE id = 1;。在修改 balance 之前，数据库会将 id = 1 用户的原始 balance 值存储在 Undo Log 中。如果事务回滚，系统会从 Undo Log 中恢复 balance 的原始值。
二、Redo Log
Redo Log是重做日志，主要用于恢复已经提交的事务，确保数据库的持久性（Durability）。当数据库发生崩溃时，Redo Log 可以帮助恢复已经提交但尚未写入磁盘的数据。
1. 工作原理
作用：Redo Log 记录的是对数据库的物理层面的修改，确保当系统崩溃时，已经提交的事务所做的修改不会丢失。通过 Redo Log，MySQL 能够在崩溃后重做已提交事务的修改，保证事务的持久性。
事务提交时：当事务提交时，MySQL 并不会立即将所有数据刷新到磁盘（因为磁盘 IO 较慢），而是先将修改内容记录到 Redo Log 中，之后再异步地将数据写入磁盘。
例如：
在执行一条 INSERT、UPDATE 或 DELETE 操作时，数据库会先将修改记录写入 Redo Log。当事务提交时，系统会将 Redo Log 刷入磁盘，保证数据不会丢失。
即使数据库此时宕机，数据页尚未持久化，但因为有 Redo Log，系统可以在重启后重新应用日志，恢复已提交的事务。
2. Redo Log 的实现
物理日志：Redo Log 是物理日志，记录的是物理数据页的更改，而不是 SQL 操作或逻辑操作。它记录了数据库物理块的变更，比如某个数据页上某条记录的修改。
WAL（Write-Ahead Logging）机制：InnoDB 采用 WAL 机制，即先写日志，再写磁盘。每次事务提交时，InnoDB 会将 Redo Log 先写入磁盘，而后再慢慢将实际修改的数据写入磁盘。
循环写机制：Redo Log 采用固定大小的循环写机制。当日志写满时，会从头开始重新写。因此，在系统运行时，InnoDB 会定期将日志应用到数据页，并将脏页（即被修改但还未写入磁盘的数据页）刷新到磁盘。
3. Redo Log 的使用场景
崩溃恢复：当数据库崩溃后，通过重启，MySQL 可以根据 Redo Log 恢复所有已提交的事务。这是 MySQL 保证事务持久性的关键机制。
提高性能：因为 Redo Log 可以先于数据页写入磁盘，数据库无需每次事务提交时都立即写入数据页，从而显著提高了写操作的性能。数据页的写入可以在稍后的时间由后台线程异步完成。
4. 示例
假设执行一条 UPDATE 语句：UPDATE user SET balance = balance + 100 WHERE id = 1;。当事务提交时，MySQL 会将修改后的 balance 值写入 Redo Log，并将 Redo Log 刷入磁盘。如果系统在修改完成后立刻崩溃，虽然数据页未刷新，但 MySQL 可以通过 Redo Log 在重启时恢复提交的事务。
三、Undo Log 和 Redo Log 的区别
尽管它们都是事务日志，但Undo Log和Redo Log有着不同的职责和工作方式。Undo Log是逻辑日志，用于撤销未完成或回滚的事务操作，而Redo Log是物理日志，用于保证已提交的事务在系统崩溃时能够得到恢复。
四、总结
Undo Log保证了事务的原子性和隔离性，在事务回滚和多版本并发控制（MVCC）中起到关键作用。
Redo Log保证了事务的持久性，在系统崩溃后可以恢复已提交的事务操作，确保数据一致性。
在数据库的世界里，Undo Log和Redo Log是两个不可或缺的守护者。它们确保了我们的数据在任何情况下都能保持一致性和完整性。通过理解它们的工作原理和使用场景，我们可以更好地利用它们来保护我们的数据。
