-
redo：崩溃恢复、引擎层、物理+逻辑，保证持久性
-
undo：事务回滚+MVCC、引擎层、逻辑，保证原子性
-
binlog：主从同步、归档、Server层、逻辑SQL，数据备份
一、详细对照表
对比项 redo log undo log binlog
归属层 InnoDB引擎层 InnoDB引擎层 MySQL Server层，所有引擎都生成
作用 宕机崩溃恢复(WAL)，落地脏页 事务回滚 + MVCC多版本快照读 主从复制、数据恢复、审计
日志内容 物理日志：修改的数据页内容 逻辑日志：反向SQL(原值) 逻辑日志：完整执行SQL/DML
写入时机 修改数据前(WAL) 修改数据前生成旧数据 事务提交最后一步写入磁盘
落盘规则 循环覆写（ib_logfile固定大小） 事务提交不立即删，purge后台回收 追加写入，永久留存，可配置过期删除
事务关系 所有DML都会生成 DML生成，DDL很少 提交才写入，失败回滚不生成
文件位置 ib_logfile0/1 undo表空间undo001 mysql-bin.xxx
二、一条update完整写入顺序（重点）
-
先查数据页到BufferPool
-
生成undo日志写入undo buffer
-
生成redo日志写入redo buffer
-
修改内存中数据页（脏页）
-
事务commit：刷redo到磁盘；写入binlog落盘
-
后台线程随机刷脏页到磁盘
宕机：靠redo恢复脏页；回滚：靠undo还原；主从同步：靠binlog
三、三种日志解决什么问题
-
redo → 解决宕机丢数据（持久性）
内存脏页没刷盘，库崩了，重启用redo重做数据。
-
undo → 事务回滚+快照读（原子性+隔离）
事务失败回退旧数据；MVCC靠undo链条生成历史版本。
-
binlog → 备份、主从、时间点恢复
innodb之外引擎没有redo/undo，全靠binlog记录数据变更。
四、补充区分（高频坑）
-
redo是循环日志，满了覆盖；binlog是追加日志，不会覆盖
-
undo不会立即删除：事务提交后，有快照在读就保留，purge线程定时清理
-
binlog三种格式：
• statement：记SQL语句
• row：记行变更（主从最稳，默认）
• mixed：混合
五、Seata undolog 额外区分
Seata的undolog不属于MySQL三大日志，存业务数据快照，用于分布式AT回滚。