前置InnoDB才有 redo log、undo logbinlog 是 MySQL Server 层日志所有引擎都可以产生。区分redo log重做日志保证事务【持久性】崩溃恢复已经提交的数据不丢undo log回滚日志保证事务【原子性】事务失败可以回滚保存数据修改前的旧版本同时支撑 MVCCbinlog二进制日志记录数据库【变更事件】用于主从复制、数据备份恢复一、redo log重做日志InnoDB 引擎层作用实现崩溃恢复crash-safe事务提交时先写 redo log刷盘再慢慢刷内存脏页到磁盘数据文件。如果数据库宕机重启后扫描 redo log把已经提交但还没落盘到 ibd 文件的数据重做。优化磁盘 IO不是每次修改都直接写磁盘数据文件随机 IO而是顺序写 redo log提升写入性能。核心记录「数据页做了什么修改」记录的是物理页变更不是 SQL 语句。 结构固定大小的循环文件组ib_logfile0、ib_logfile1环形复用。写入流程WAL 预写日志WALWrite-Ahead Logging先写日志再写数据修改内存缓冲池 buffer pool 里的数据页脏页生成 redo log 记录写入 redo log buffer事务 commit 时把 redo log buffer 刷入磁盘 redo log 文件这一步成功 事务持久化成功后台线程page cleaner异步慢慢把脏页刷到磁盘 ibd 数据文件即使第 4 步没做完、数据库宕机重启后读 redo log把这部分变更重做。场景示例表 userid 主键update user set name张三 where id1;id1 这条记录的数据页加载到 buffer pool 内存内存中把 name 改成张三该页变成脏页InnoDB 生成 redo log记录「XX 数据页偏移量 xx 位置把旧值改成张三」物理修改commitredo log 落盘。此时事务提交成功就算脏页还没写入 ibd 文件也没关系突然断电内存脏页丢失但是 redo log 已经保存在磁盘。MySQL 重启读取 redo log找到这条已经提交的修改把数据页恢复保证数据不丢失。⚠️ redo log 只记录 InnoDB 数据页改动不能用来回滚事务。二、undo log回滚日志InnoDB 引擎层作用原子性事务回滚事务执行出错 /rollback 时用 undo log 把数据恢复成修改前的样子。MVCC 多版本并发控制保存数据修改前的历史快照版本实现不加锁的读快照读select隔离读。核心记录修改前的数据快照逻辑记录不是物理页。注意undo log 在事务执行阶段就写入不是 commit 才写。场景示例同样语句update user set name张三 where id1;原来 name 李四开启事务读取 id1 记录先写 undo log记录这条记录修改前的数据 name 李四再修改 buffer pool 里数据生成 redo log情况 A执行rollback回滚 InnoDB 读取 undo log 里的旧值 name 李四把内存数据恢复回去事务撤销。情况 Bcommit 提交事务 事务提交成功undo log 不会立刻删除。如果有其他事务此时做快照读依然可以读到 undo 里保存的旧版本name李四实现 MVCC。 等没有任何事务再引用这个版本purge 后台线程清理 undo 日志。关键点undo log 用来回滚 提供历史版本redo log 保证 undo log 本身修改的持久性修改 undo 页本身也会写 redo log三、binlog二进制日志MySQL Server 层作用主从复制主库执行完事务写入 binlog从库拉取 binlog重放 SQL 实现数据同步。时间点数据备份恢复全量备份 binlog可以恢复到任意时间点。核心逻辑日志记录 SQL 事件DML/DDL不是物理页。 三种格式statement记录原始 SQL简单但函数、随机函数会有主从不一致问题row推荐记录行变更前后数据和 SQL 无关主从最安全日志体积大mixed混合模式写入时机事务 commit 时在 redo log 之后写入 binlog有两阶段提交 2PC 保证 redo log 和 binlog 一致性防止 redo 写成功 binlog 失败或者反过来导致主从数据不一致。场景示例update user set name张三 where id1;binlog 为 row 格式事务执行修改数据生成 undo、redocommit 阶段写 redo logprepare 阶段写入 binlogredo log 标记 commitbinlog 记录id1 这一行旧 name 李四新 name 张三行变更记录主从场景从库同步拉取 binlog重放这行变更从库数据同步更新。数据误删恢复场景 比如 10:00 执行 update 改错数据。我们用之前的全量备份恢复到 9:00然后用 binlog 回放 9:00~10:00 之间日志跳过错误那条 SQL恢复数据。binlog不负责崩溃恢复宕机后不会用 binlog 恢复当前实例数据崩溃恢复只靠 redo log。四、三者横向对比表日志所属层日志类型核心目的生命周期redo logInnoDB 引擎层物理日志数据页改动崩溃恢复持久性循环覆盖undo logInnoDB 引擎层逻辑快照修改前数据事务回滚、MVCC事务提交后延迟 purge 清理binlogMySQL Server 层逻辑日志SQL / 行变更主从复制、时间点备份追加写入文件滚动手动清理五、完整事务执行串联例子三合一事务begin; update user set name张三 where id1; --原值name李四 commit;begin 开启事务找到 id1 行写入 undo log保存旧值 name 李四buffer pool 修改内存记录为 name 张三生成 redo log记录数据页物理变更commit 进入 2PCredo log prepare 落盘写 binlog记录行变更李四→张三落盘redo log 标记 commit事务提交成功脏页还在内存后续 page cleaner 异步刷 ibd 文件undo log 保留一段时间给其他事务快照读后续 purge 清理binlog 文件保留给从库同步 / 备份如果此时断电MySQL 重启扫描 redo log发现这条 prepare 成功、binlog 也写入完成自动提交事务数据持久化。如果 prepare 阶段断电binlog 没写成功事务回滚。六、总结redo logWALcrash-safe物理页引擎层循环写。持久性undo log回滚 MVCC保存旧版本逻辑记录引擎层。原子性 隔离binlogserver 层逻辑日志主从、备份追加写。复制、时间点恢复2PC保证 redo 和 binlog 两个日志的事务一致性防止主从数据不一致一句话区分redo怕宕机丢已经提交的数据undo可以反悔回滚给 MVCC 读旧数据binlog给别的库从库同步做备份物理日志记录「磁盘上哪个位置、改成什么数据」面向数据页 / 磁盘块。逻辑日志记录「执行了什么 SQL 操作、要修改哪行数据」面向行 / 业务逻辑。MySQL InnoDB 三大日志redo log物理日志偏物理undo log逻辑日志binlog逻辑日志1. redo log重做日志—— 物理日志InnoDB 的崩溃恢复用属于物理日志记录的是数据页的修改不是 SQL也不是行记录。举例子 表userid1nameA执行update user set nameB where id1;redo log 不会记update user set nameB where id1;也不会简单记id1 name从A改成B。redo log 记录的是表空间号 数据页号 页内偏移量 修改后的字节内容(space:1, page:100, offset:20, new_valueB)含义磁盘上这个数据页的这个位置把字节改成 B。✅ 物理日志特点操作对象是磁盘数据页不是行、不是 SQL恢复时直接把日志里的字节覆盖写到对应数据页只属于 InnoDB 引擎server 层看不到幂等重复回放多少次结果都一样。补充redo log 是物理日志但带少量行信息行业习惯统一归类为物理日志不要纠结 “纯物理” 这个字眼。2. undo log回滚日志—— 逻辑日志事务回滚、MVCC 读快照用逻辑日志。同样这条 updateupdate user set nameB where id1;undo log 记录id1, name原来的值是A不是记录磁盘哪个字节而是记录逻辑上旧行数据。 事务要回滚的时候执行一个反向逻辑操作把name改回A。✅ 逻辑日志特点记录数据变更的逻辑内容旧行不是磁盘字节回滚不是 “擦除磁盘页”而是执行反向逻辑操作属于 InnoDB 内部日志。重点区分 redo vs undo redo新值物理崩溃恢复 undo旧值逻辑事务回滚 / MVCC。3. binlog二进制日志—— 逻辑日志MySQL Server 层主从复制、数据备份用在 MySQL Server 层和存储引擎无关。同样 update 语句binlog 有 3 种格式statement 格式语句级逻辑直接记录 SQLupdate user set nameB where id1;row 格式行级逻辑生产默认记录哪一行修改前和修改后数据表userid1name由A → Bmixed混合上面两种binlog不会记录磁盘页、偏移、字节。 主库同步给从库从库拿到 binlog解析这条逻辑变更在自己引擎里重新执行修改行。✅ binlog 逻辑日志特点Server 层日志InnoDB/MyISAM 都可以产生记录的是业务逻辑变更SQL 或者行变更主从复制靠它row 模式下是行级逻辑依然不是物理页。汇总对比表表格日志类型记录内容作用redo log物理日志数据页 偏移 新字节崩溃恢复保证刷盘前数据安全undo log逻辑日志修改前旧行数据事务回滚、MVCC