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文件，否则实例无法启动
