这是一个非常核心的MySQL特别是InnoDB问题。binlog,redo log, 和undo log是构成MySQL数据安全和高可用基石的三类日志它们各自有不同的职责和应用场景。为了更直观地理解我们先通过一个流程图来看一条更新语句UPDATE t SET cc1 WHERE id1;是如何与这三种日志交互的最终数据落盘日志写入与刷盘InnoDB引擎内部请求数据找到id1的数据行旧值写入设置新值记录物理修改记录逻辑操作提交时刷盘提交时刷盘定期或日志满时客户端发送UPDATE语句Executor执行器Buffer Pool返回旧值Undo Log用于回滚和MVCCRedo Log Buffer用于崩溃恢复Binlog Cache用于主从复制事务提交将Redo Log Buffer刷盘(Write-Ahead Logging)根据sync_binlog设置将Binlog刷盘写入Binlog后通知存储引擎提交Checkpoint机制将Buffer Pool中脏页刷回磁盘上图展示了三种日志产生的核心时机下面是它们各自作用的详细解释。1. Redo Log (重做日志)所属InnoDB存储引擎层特有的日志。物理性质记录的是物理日志即“在某个数据页上做了什么修改”。比如“将第5号表空间的第100号页面的偏移量为10的位置的值更新为xxx”。作用崩溃恢复 (Crash Recovery)这是它的核心作用。确保事务的持久性Durability。即使发生宕机已经提交的事务所做的修改也不会丢失。Write-Ahead Logging (WAL)为了实现崩溃恢复InnoDB采用了WAL技术即所有对数据页的修改都必须先写入Redo Log然后再写入内存中的Buffer Pool。这样即使修改后的数据页脏页还没来得及刷盘就宕机了重启后也能通过重放Redo Log来重新应用这些修改。作用时机事务执行过程中SQL语句修改数据时会先写到重做日志缓冲区Redo Log Buffer。事务提交时为了保证持久性事务提交时必须将对应的Redo Log记录刷盘具体刷盘策略由innodb_flush_log_at_trx_commit参数控制可权衡性能与安全。后台线程定期Redo Log Buffer中的内容也会由后台主线程定期刷盘。应用场景数据库宕机重启后自动恢复所有已提交的事务。作为WAL机制的核心它将随机写磁盘数据页转换为了顺序写磁盘Redo Log大大提升了数据库的写入性能。2. Undo Log (回滚日志)所属InnoDB存储引擎层特有的日志。逻辑性质记录的是逻辑日志。当一条记录被修改时Undo Log会记录一条与当前操作相反的逻辑操作。例如如果是INSERT则记录一条DELETE。如果是DELETE则记录一条INSERT包含所有列的值。如果是UPDATE则记录一个反向的UPDATE将更新后的值改回更新前的值。作用事务回滚 (Transaction Rollback)确保事务的原子性Atomicity。如果事务需要回滚InnoDB引擎就会使用Undo Log中的信息将数据恢复到事务开始前的状态。多版本并发控制 (MVCC)这是它的另一个极其重要的作用。当某个事务需要读取一行记录时如果该记录正在被其他事务修改或已被修改但未提交InnoDB会通过Undo Log来构建该行记录的一个早期版本快照供其他事务读取。这实现了非锁定读是READ COMMITTED和REPEATABLE READ隔离级别的基础。作用时机事务进行中在任何数据修改操作INSERT/DELETE/UPDATE发生之前都会先记录对应的Undo Log。事务回滚时利用Undo Log执行反向操作。一致性读时当其他会话需要读取旧版本数据以实现MVCC时。应用场景执行ROLLBACK语句时。支撑READ COMMITTED和REPEATABLE READ隔离级别下的快照读。系统自动回滚如事务执行过程中发生死锁或被KILL。3. Binlog (二进制日志)所属MySQL Server层记录的日志所有存储引擎都可以使用。逻辑性质记录的是逻辑日志即SQL语句本身STATEMENT格式或行更改后的值ROW格式默认或者是两者的混合MIXED格式。作用主从复制 (Replication)这是它的核心作用。Master将Binlog发送给SlaveSlave重放Replay这些日志从而实现数据同步。数据恢复 (Point-in-Time Recovery)由于Binlog记录了所有更改数据库的操作可以通过重放Binlog来恢复某个时间点之后的数据。例如每天凌晨有一个全量备份那么可以用全量备份 从凌晨到故障前的Binlog来进行完整恢复。作用时机事务提交时在事务提交完成后才会将整个事务的Binlog按顺序写入到二进制日志文件中这保证了从库上事务执行的顺序与主库一致。刷盘时机由参数sync_binlog控制权衡性能与数据安全。应用场景搭建MySQL主从集群或读写分离。基于时间点的数据恢复和增量备份。三者的协同工作两阶段提交 (2PC)从流程图可以看到在事务提交时Redo Log和Binlog必须保持一致性否则会导致主从数据不一致或恢复后数据错误。为此InnoDB使用了内部的两阶段提交2-Phase Commit, 2PC协议。Prepare阶段InnoDB将事务的Redo Log写入并刷盘然后将Redo Log标记为PREPARE状态。Commit阶段MySQL Server将事务的Binlog写入并刷盘。刷盘成功后InnoDB才会将Redo Log标记为COMMIT状态事务才算真正提交完成。这种机制保证了如果Binlog写失败事务会回滚因为Redo Log是Prepare状态但找不到对应的Binlog。如果Binlog写成功但Redo Log的Commit标记写失败在崩溃恢复时发现Redo Log是Prepare状态且存在对应的Binlog则会自动提交事务保证数据一致。总结对比表特性Redo LogUndo LogBinlog所属层级InnoDB引擎层InnoDB引擎层MySQL Server层日志性质物理日志记录对页的修改逻辑日志记录反向SQL逻辑日志记录SQL或行更改主要作用崩溃恢复保证持久性事务回滚和MVCC保证原子性和隔离性主从复制和数据恢复写入时机事务过程中、提交时WAL数据修改前事务提交后按顺序生命周期事务提交后被覆盖循环使用事务提交后放入删除链表由purge线程清理当无快照读需要时事务提交后可长期保留取决于expire_logs_days是否可删循环写入固定大小可被purge线程清理可手动或自动 purge