InnoDB中的redo log和undo log机制

标签：事务 log 数据库 Undo InnoDB redo Log

1.redo log:

Redo Log 是数据库系统（尤其是 MySQL 的 InnoDB 存储引擎）中用于实现事务持久性的重要机制。它记录了事务对数据库所做的修改，确保即使数据库发生崩溃，事务的提交仍然不会丢失。

事务开始：
当事务执行开始时，任何对数据的修改都会先写入 redo log，而不是直接写入磁盘中的数据页。
写入内存：
修改的数据首先会写入内存中的缓冲池，并在内存中更新数据页，同时记录这次修改的操作到 redo log 缓冲区中。
写入磁盘：事务提交时，InnoDB 会将 redo log 缓冲区的内容持久化到磁盘中的 redo log 文件中（即“预写日志”原则，WAL，Write-Ahead Logging），确保即使系统崩溃，仍可以通过 redo log 恢复事务。
数据刷入磁盘：数据页的实际刷盘操作（即将内存中的数据页持久化到磁盘）并不需要立刻完成，数据库可以延迟将数据刷入磁盘。这意味着 redo log 能够保证数据的完整性，即使数据页还没有完全写入磁盘。
崩溃恢复：如果数据库发生故障，InnoDB 会在重启时通过 redo log 进行崩溃恢复。它会根据 redo log 的内容，重做所有已提交但尚未写入磁盘的数据修改，确保数据的一致性。

Redo Log：由存储引擎（如 InnoDB）生成，记录数据的物理修改，用于崩溃恢复。
Binlog：由 MySQL Server 生成，记录逻辑 SQL 操作，用于主从复制和数据库恢复。
通过 redo log，数据库能够实现事务的持久性（Durability），即使在意外中断或崩溃的情况下，已提交的事务仍能被恢复。

Undo Log 是数据库系统（如 MySQL 的 InnoDB 存储引擎）中用于实现事务回滚和**多版本并发控制（MVCC）**的重要机制。它记录了事务在执行过程中所做的修改之前的数据快照，从而支持事务的回滚以及提供一致的读视图。

事务开始：当事务修改数据时，InnoDB 会将修改前的旧数据（即原始数据）记录到 Undo Log 中，以便在事务回滚时恢复原始状态。
回滚操作：如果事务执行过程中发生错误或主动执行回滚操作，数据库会使用 Undo Log 将数据恢复到修改前的状态，从而撤销事务对数据库的影响。
多版本并发控制（MVCC）：在并发控制中，未提交的事务会对数据进行修改，而其他事务需要读取一致的数据快照。在这种情况下，数据库可以通过 Undo Log 提供修改前的数据版本，从而实现快照读，避免读取到未提交的数据。这样，事务可以在不加锁的情况下，读到一致性视图的数据。

用于回滚：Undo Log 保存的是事务修改前的旧值，因此可以在回滚时使用这些旧值恢复数据库原来的状态。无论事务是主动回滚还是由于系统故障引发的回滚，Undo Log 都能确保数据恢复到事务之前的状态。
支持 MVCC：多版本并发控制（MVCC）依赖 Undo Log 机制来维护多个数据版本。通过 Undo Log，数据库可以为不同的事务提供不同的历史版本数据，从而实现非阻塞读操作。
存储方式：Undo Log 记录的数据并不会直接存储在独立的文件中，而是存放在系统表空间（System Tablespace）或者独立的 undo 表空间中。
删除延迟：当事务修改数据并提交时，这些修改可能会覆盖旧数据。然而，数据库并不会立即删除 Undo Log，特别是在有其他事务依赖这些旧版本数据时。只有当没有事务需要使用旧版本数据时，Undo Log 才会被回收。

总之，Undo Log 在数据库中主要用于提供事务的回滚能力和支持一致性读，尤其在并发场景下，通过 Undo Log 保持数据的多个版本，使得事务在读写时能够相互独立，提高了并发性能。

标签：事务,log,数据库,Undo,InnoDB,redo,Log
From： https://blog.csdn.net/m0_73163793/article/details/142050573