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机制的重要一步。