MySQL事务日志由redo log和undo log组成：redo log通过WAL机制保障持久性，顺序写入循环文件；undo log记录逻辑反向操作，支持回滚与MVCC；binlog属Server层逻辑日志，用于复制与备份，不参与崩溃恢复。

MySQL事务日志不是单一文件，而是由InnoDB存储引擎维护的一组关键日志机制，核心包括redo log（重做日志）和undo log（回滚日志）。它们分处不同层级、承担不同职责，共同支撑ACID中的原子性与持久性。

redo log：保障事务持久性的“安全垫”

它记录的是对数据页的物理修改操作，比如“将页号123中偏移量456处的值从0x11改为0x22”。关键特点是：

• 采用预写式日志（WAL）：事务提交前，必须先把redo日志刷到磁盘（通过innodb_flush_log_at_trx_commit控制），再标记事务为已提交
• 顺序追加写入，落在ib_logfile0、ib_logfile1等固定大小的循环文件中，避免随机IO，性能高
• 崩溃恢复时，MySQL重启会自动重放（redo）所有已提交但尚未刷入表空间的变更，确保不丢数据

undo log：实现原子性与MVCC的“时间机器”

它记录的是逻辑反向操作，比如“把某行的name字段从'张三'改回'李四'”，不直接还原页面，而是按需构造前镜像。主要用途有：

• 事务回滚：执行ROLLBACK时，用undo log逆向撤销未提交的修改
• MVCC快照读：SELECT语句在RR或RC隔离级别下，借助undo链找到对应Read View的历史版本，实现非阻塞读
• 存储在共享表空间（ibdata1）或独立undo表空间中，由purge线程异步清理过期版本

别混淆：binlog不是事务日志，但常被一起提及

binlog是Server层生成的归档日志，记录的是SQL逻辑（如INSERT/UPDATE语句），用于主从复制和全量+增量备份。它和redo/undo无关，也不参与崩溃恢复。InnoDB事务要真正落库，需同时满足：redo log落盘 + binlog落盘（两阶段提交保证一致性）。

日常运维中要注意的关键点

事务日志本身无需手动清理——redo log循环复用，undo log由系统自动purge。但配置不当会影响稳定性和性能：

• innodb_log_file_size太小会导致频繁checkpoint，拖慢写入；过大则恢复时间变长，建议单个256MB–1GB
• innodb_undo_tablespaces开启独立undo表空间，便于后期收缩和管理
• 若发现ib_logfile*异常增长或磁盘报警，优先检查是否有长事务未提交（查information_schema.INNODB_TRX）
• 不要手动删除ib_logfile*或undo文件，否则实例无法启动