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日志刷到磁盘（通过
控制），再标记事务为已提交
顺序追加写入，落在
、
等固定大小的循环文件中，避免随机IO，性能高
崩溃恢复时，MySQL重启会自动重放（redo）所有已提交但尚未刷入表空间的变更，确保不丢数据
undo log：实现原子性与MVCC的“时间机器”
它记录的是
逻辑反向操作
，比如“把某行的name字段从'张三'改回'李四'”，不直接还原页面，而是按需构造前镜像。主要用途有：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
事务回滚：执行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。但配置不当会影响稳定性和性能：
太小会导致频繁checkpoint，拖慢写入；过大则恢复时间变长，建议单个256MB–1GB
开启独立undo表空间，便于后期收缩和管理
若发现
异常增长或磁盘报警，优先检查是否有长事务未提交（查
）
不要手动删除
或undo文件，否则实例无法启动
innodb_flush_log_at_trx_commitib_logfile0ib_logfile1innodb_log_file_sizeinnodb_undo_tablespacesib_logfile*information_schema.INNODB_TRXib_logfile*