mysql事务日志由redo Log 和 Undo Log 组成，Redo Log 通过先写日志再写数据的机制确保持久性，宕机后重放日志恢复已提交事务；Undo Log 记录修改前数据用于回滚和 MVCC，保障原子性与一致性；二者协同实现 InnoDB 的 ACID 特性，并在崩溃恢复时自动完成数据修复。
MySQL数据库 的正常运行离不开事务日志的支持，尤其是使用 InnoDB 存储引擎时。事务日志是确保数据持久性、一致性和崩溃恢复能力的核心机制之一。它记录了所有对数据库进行修改的操作，以便在系统异常重启后能将 数据恢复 到一致状态。
事务日志的基本概念
在 MySQL 中，事务日志主要指 重做日志（Redo Log）和 回滚日志（Undo Log），它们由 InnoDB 存储引擎维护。
- Redo Log（重做日志）：记录事务对数据页所做的物理修改，用于保证事务的持久性。即使事务提交后系统崩溃，也可以通过重做日志重新执行这些操作，确保数据不丢失。
- Undo Log（回滚日志）：记录事务修改前的数据状态，用于支持事务回滚和多版本 并发 控制（MVCC）。当事务需要回滚时，可以通过 Undo Log 恢复原始数据。
这两种日志协同工作，使 InnoDB 具备了 ACID 特性中的原子性、一致性与持久性。
Redo Log 的工作机制
Redo Log 采用预写日志（Write-Ahead Logging, WAL）策略，即“先写日志，再写数据”。具体流程如下：
- 事务执行过程中，InnoDB 会先把修改操作写入 Redo Log 缓冲区（内存中）。
- 当事务提交时，Redo Log 缓冲区的内容会被刷新到磁盘上的 Redo Log 文件中（默认为 ib_logfile0 和 ib_logfile1）。
- 数据页的修改可以稍后 异步 写入表空间文件，不必立即落盘。
这种机制大大减少了随机磁盘 I /O，提高了写性能。同时，若发生宕机，MySQL 重启后可通过重放 Redo Log 来恢复未写入数据文件的已提交事务。
Undo Log 与事务回滚和 MVCC
Undo Log 保存的是数据修改前的快照，其主要作用包括：
- 支持事务回滚：当执行 ROLLBACK 命令时，InnoDB 利用 Undo Log 将 数据恢复 到事务开始前的状态。
- 实现 MVCC：多个事务并发读取同一行数据时，系统根据事务隔离级别和 Undo Log 构建历史版本，避免读写冲突，提升并发性能。
Undo Log 也存储在表空间中，InnoDB 5.6 之后引入独立的 Undo Tablespace，便于管理和优化。
事务日志与数据库恢复
当 MySQL 意外关闭后重启，InnoDB 会自动进入恢复模式：
- 通过 Redo Log 重放已提交但未写入数据文件的事务。
- 对于未提交的事务，使用 Undo Log 进行回滚，确保数据一致性。
这个过程对用户透明，保障了数据库在故障后的可靠性和数据完整性。
基本上就这些。理解 MySQL 事务日志的工作原理，有助于更好地设计高并发应用、优化性能以及应对突发故障。掌握 Redo 和 Undo 日志的作用，是深入理解 InnoDB 机制的重要一步。
