一、概述MySQL 的日志系统是数据库可靠性与一致性的基石。三大日志各司其职共同保障事务的 ACID 特性日志类型核心作用保障特性所属层级Redo Log崩溃恢复、持久化保证持久性 (Durability)InnoDB 存储引擎层Undo Log事务回滚、多版本并发控制原子性 (Atomicity)、隔离性 (Isolation)InnoDB 存储引擎层Binlog主从复制、数据归档与恢复一致性 (Consistency)MySQL Server 层二、Redo Log重做日志2.1 核心原理Redo Log 是InnoDB 存储引擎特有的物理日志采用WALWrite-Ahead Logging预写日志机制。WAL 核心思想先写日志再写磁盘。当数据修改时先将修改记录到 Redo Log事务即可提交成功数据页可以稍后异步刷盘。物理日志格式记录的是在某个数据页上做了什么修改例如对 表空间X 的数据页Y 的偏移量Z 处写入数据A2.2 为什么需要 Redo Log直接刷盘数据页存在两大问题性能问题数据页大小为 16KB可能只修改了几字节却要刷整个页且是随机写数据页在磁盘上位置分散可靠性问题Buffer Pool 基于内存断电后脏页数据会丢失Redo Log 的优势记录内容精简仅需几十字节表空间号、数据页号、偏移量、更新值顺序写性能远高于随机写事务提交时只需保证 Redo Log 持久化无需等待脏页刷盘2.3 存储结构与刷盘策略存储结构固定大小的循环文件默认ib_logfile0和ib_logfile1写满后从头开始覆盖仅保留未刷盘的脏页日志刷盘策略由innodb_flush_log_at_trx_commit控制参数值行为安全性性能0每秒写入磁盘一次可能丢失 1 秒数据最高1每次事务提交都fsync最安全推荐生产环境较低2每次提交写入 OS 缓存由 OS 决定刷盘时机可能丢失部分数据较高生产环境建议设置为 1双 1 配置之一配合sync_binlog1确保数据安全。2.4 Crash-Safe 机制当 MySQL 崩溃重启时InnoDB 会扫描 Redo Log已提交事务重放前滚Redo Log恢复未刷盘的数据修改未提交事务结合 Undo Log 回滚这就是Crash-Safe崩溃恢复能力确保已提交事务的数据不丢失。三、Undo Log回滚日志3.1 核心原理Undo Log 是逻辑日志记录的是事务修改之前的数据状态用于实现事务回滚和 MVCC。逻辑日志格式记录反向操作INSERT→ 记录对应的DELETE信息DELETE→ 记录对应的INSERT信息UPDATE→ 记录修改前的旧值3.2 两大核心作用1. 事务回滚保证原子性事务执行过程中出现错误或执行ROLLBACK时MySQL 利用 Undo Log 将数据恢复到事务开始前的状态。执行流程示例START TRANSACTION; DELETE FROM products WHERE id 10; -- 发现删错了 ROLLBACK;执行 DELETE 前先将 id10 的完整记录写入 Undo Log标记数据行为删除状态执行 ROLLBACK 时根据 Undo Log 恢复原始数据2. MVCC多版本并发控制Undo Log 是实现 MVCC 的关键因素之一 版本链机制每行数据包含两个隐藏字段DB_TRX_ID创建或最后修改该行的事务 IDDB_ROLL_PTR指向 Undo Log 的回滚指针多个事务对同一行数据的修改会形成 Undo Log 版本链Read View Undo Log读已提交RC每次 SELECT 创建新的 Read View读取最新已提交版本可重复读RR事务开始时创建 Read View 并复用通过 Undo Log 版本链找到事务开始前的数据版本3.3 生命周期与清理机制Undo Log 管理流程事务开始时分配 Undo Log 空间位于回滚段 Rollback Segment事务执行中记录修改前的数据事务提交后Undo Log 不会立即删除需继续为 MVCC 服务Purge 线程定期检查不再被任何事务视图引用的 Undo Log 并回收监控命令SHOW ENGINE INNODB STATUS\G -- 查看 History list length持续增长说明 Purge 跟不上四、Binlog二进制日志/归档日志4.1 核心原理Binlog 是MySQL Server 层实现的逻辑日志记录所有引起数据变更的操作DDL、DML所有存储引擎都可使用。4.2 主要作用主从复制主库将 Binlog 传输到从库从库重放实现数据同步数据恢复基于时间点的恢复Point-In-Time Recovery全量备份 Binlog 增量恢复数据审计追踪数据变更历史4.3 三种记录格式格式记录内容优点缺点适用场景STATEMENT原始 SQL 语句日志量小动态函数如NOW()、UUID()可能导致主从不一致简单场景已不推荐ROW行数据修改前后的值精确复制无歧义日志量大批量更新产生大量记录生产环境推荐MIXED自动选择 STATEMENT 或 ROW折中方案切换逻辑复杂过渡方案生产建议使用binlog_formatROW配合sync_binlog1。4.4 与 Redo Log 的关键区别特性Redo LogBinlog层级InnoDB 存储引擎层MySQL Server 层日志类型物理日志页修改逻辑日志SQL/行数据写入方式循环写固定大小覆盖旧日志追加写文件满后新建保留历史用途崩溃恢复Crash Recovery主从复制、时间点恢复保留内容仅未刷盘的脏页日志全量历史变更记录五、两阶段提交2PC保证日志一致性5.1 为什么需要两阶段提交Redo Log 和 Binlog 的写入时机不同Redo Log 在事务执行过程中可不断写入Binlog 仅在事务提交时写入如果直接提交可能出现两种不一致情况情况 1先写 Redo 再写 BinlogRedo 标记提交 → 崩溃 → Binlog 未写入主库数据已更新但 Binlog 缺失从库无法同步此事务情况 2先写 Binlog 再写 RedoBinlog 写入 → 崩溃 → Redo 未标记提交主库回滚此事务但从库已执行导致主从不一致5.2 两阶段提交流程-- 阶段 1Prepare 写入 Redo Log标记为 PREPARE 状态记录 XID事务 ID -- 阶段 2Commit 写入 Binlog 更新 Redo Log 为 COMMIT 状态崩溃恢复判断逻辑Redo 为 PREPARE 且 Binlog 存在对应 XID → 提交事务Redo 为 PREPARE 但 Binlog 无对应 XID → 回滚事务六、事务执行全流程以UPDATE操作为例展示三大日志的协作┌─────────────────────────────────────────────────────────────┐ │ 1. 开启事务 │ │ └─► 分配 Rollback Segment准备 Undo Log 空间 │ ├─────────────────────────────────────────────────────────────┤ │ 2. 执行 UPDATE │ │ ├─► 记录修改前的旧值到 Undo LogBuffer Pool 中的 Undo 页│ │ ├─► 修改 Buffer Pool 中的数据页标记为脏页 │ │ └─► 将修改记录到 Redo Log Buffer │ ├─────────────────────────────────────────────────────────────┤ │ 3. 事务提交两阶段提交 │ │ ├─► 阶段 1Redo Log PREPARE刷盘 │ │ ├─► 写入 Binlog刷盘 │ │ └─► 阶段 2Redo Log COMMIT │ ├─────────────────────────────────────────────────────────────┤ │ 4. 后台异步刷脏页Checkpoint │ │ └─► 脏页刷盘后对应 Redo Log 空间可被重用 │ ├─────────────────────────────────────────────────────────────┤ │ 5. Purge 线程清理 Undo Log │ │ └─► 当无事务需要旧版本数据时清理过期 Undo Log │ └─────────────────────────────────────────────────────────────┘七、总结日志核心职责关键机制生产配置建议Redo Log保证已提交事务不丢失WAL、顺序写、循环覆盖innodb_flush_log_at_trx_commit1Undo Log支持回滚和 MVCC版本链、Purge 清理监控 History list length避免膨胀Binlog主从复制与数据恢复两阶段提交、ROW 格式binlog_formatROWsync_binlog1三大日志协同保障 ACID原子性AUndo Log 实现回滚一致性CRedo Undo Binlog 共同保证崩溃后的一致性状态隔离性IUndo Log 支持 MVCC 实现非锁定读持久性DRedo Log 保证已提交事务不丢失掌握这三大日志的底层原理是构建高可用、高性能 MySQL 数据库架构的基础
MySQL 三大日志系统深度解析：Binlog、Redo Log、Undo Log
发布时间：2026/5/26 1:07:58
一、概述MySQL 的日志系统是数据库可靠性与一致性的基石。三大日志各司其职共同保障事务的 ACID 特性日志类型核心作用保障特性所属层级Redo Log崩溃恢复、持久化保证持久性 (Durability)InnoDB 存储引擎层Undo Log事务回滚、多版本并发控制原子性 (Atomicity)、隔离性 (Isolation)InnoDB 存储引擎层Binlog主从复制、数据归档与恢复一致性 (Consistency)MySQL Server 层二、Redo Log重做日志2.1 核心原理Redo Log 是InnoDB 存储引擎特有的物理日志采用WALWrite-Ahead Logging预写日志机制。WAL 核心思想先写日志再写磁盘。当数据修改时先将修改记录到 Redo Log事务即可提交成功数据页可以稍后异步刷盘。物理日志格式记录的是在某个数据页上做了什么修改例如对 表空间X 的数据页Y 的偏移量Z 处写入数据A2.2 为什么需要 Redo Log直接刷盘数据页存在两大问题性能问题数据页大小为 16KB可能只修改了几字节却要刷整个页且是随机写数据页在磁盘上位置分散可靠性问题Buffer Pool 基于内存断电后脏页数据会丢失Redo Log 的优势记录内容精简仅需几十字节表空间号、数据页号、偏移量、更新值顺序写性能远高于随机写事务提交时只需保证 Redo Log 持久化无需等待脏页刷盘2.3 存储结构与刷盘策略存储结构固定大小的循环文件默认ib_logfile0和ib_logfile1写满后从头开始覆盖仅保留未刷盘的脏页日志刷盘策略由innodb_flush_log_at_trx_commit控制参数值行为安全性性能0每秒写入磁盘一次可能丢失 1 秒数据最高1每次事务提交都fsync最安全推荐生产环境较低2每次提交写入 OS 缓存由 OS 决定刷盘时机可能丢失部分数据较高生产环境建议设置为 1双 1 配置之一配合sync_binlog1确保数据安全。2.4 Crash-Safe 机制当 MySQL 崩溃重启时InnoDB 会扫描 Redo Log已提交事务重放前滚Redo Log恢复未刷盘的数据修改未提交事务结合 Undo Log 回滚这就是Crash-Safe崩溃恢复能力确保已提交事务的数据不丢失。三、Undo Log回滚日志3.1 核心原理Undo Log 是逻辑日志记录的是事务修改之前的数据状态用于实现事务回滚和 MVCC。逻辑日志格式记录反向操作INSERT→ 记录对应的DELETE信息DELETE→ 记录对应的INSERT信息UPDATE→ 记录修改前的旧值3.2 两大核心作用1. 事务回滚保证原子性事务执行过程中出现错误或执行ROLLBACK时MySQL 利用 Undo Log 将数据恢复到事务开始前的状态。执行流程示例START TRANSACTION; DELETE FROM products WHERE id 10; -- 发现删错了 ROLLBACK;执行 DELETE 前先将 id10 的完整记录写入 Undo Log标记数据行为删除状态执行 ROLLBACK 时根据 Undo Log 恢复原始数据2. MVCC多版本并发控制Undo Log 是实现 MVCC 的关键因素之一 版本链机制每行数据包含两个隐藏字段DB_TRX_ID创建或最后修改该行的事务 IDDB_ROLL_PTR指向 Undo Log 的回滚指针多个事务对同一行数据的修改会形成 Undo Log 版本链Read View Undo Log读已提交RC每次 SELECT 创建新的 Read View读取最新已提交版本可重复读RR事务开始时创建 Read View 并复用通过 Undo Log 版本链找到事务开始前的数据版本3.3 生命周期与清理机制Undo Log 管理流程事务开始时分配 Undo Log 空间位于回滚段 Rollback Segment事务执行中记录修改前的数据事务提交后Undo Log 不会立即删除需继续为 MVCC 服务Purge 线程定期检查不再被任何事务视图引用的 Undo Log 并回收监控命令SHOW ENGINE INNODB STATUS\G -- 查看 History list length持续增长说明 Purge 跟不上四、Binlog二进制日志/归档日志4.1 核心原理Binlog 是MySQL Server 层实现的逻辑日志记录所有引起数据变更的操作DDL、DML所有存储引擎都可使用。4.2 主要作用主从复制主库将 Binlog 传输到从库从库重放实现数据同步数据恢复基于时间点的恢复Point-In-Time Recovery全量备份 Binlog 增量恢复数据审计追踪数据变更历史4.3 三种记录格式格式记录内容优点缺点适用场景STATEMENT原始 SQL 语句日志量小动态函数如NOW()、UUID()可能导致主从不一致简单场景已不推荐ROW行数据修改前后的值精确复制无歧义日志量大批量更新产生大量记录生产环境推荐MIXED自动选择 STATEMENT 或 ROW折中方案切换逻辑复杂过渡方案生产建议使用binlog_formatROW配合sync_binlog1。4.4 与 Redo Log 的关键区别特性Redo LogBinlog层级InnoDB 存储引擎层MySQL Server 层日志类型物理日志页修改逻辑日志SQL/行数据写入方式循环写固定大小覆盖旧日志追加写文件满后新建保留历史用途崩溃恢复Crash Recovery主从复制、时间点恢复保留内容仅未刷盘的脏页日志全量历史变更记录五、两阶段提交2PC保证日志一致性5.1 为什么需要两阶段提交Redo Log 和 Binlog 的写入时机不同Redo Log 在事务执行过程中可不断写入Binlog 仅在事务提交时写入如果直接提交可能出现两种不一致情况情况 1先写 Redo 再写 BinlogRedo 标记提交 → 崩溃 → Binlog 未写入主库数据已更新但 Binlog 缺失从库无法同步此事务情况 2先写 Binlog 再写 RedoBinlog 写入 → 崩溃 → Redo 未标记提交主库回滚此事务但从库已执行导致主从不一致5.2 两阶段提交流程-- 阶段 1Prepare 写入 Redo Log标记为 PREPARE 状态记录 XID事务 ID -- 阶段 2Commit 写入 Binlog 更新 Redo Log 为 COMMIT 状态崩溃恢复判断逻辑Redo 为 PREPARE 且 Binlog 存在对应 XID → 提交事务Redo 为 PREPARE 但 Binlog 无对应 XID → 回滚事务六、事务执行全流程以UPDATE操作为例展示三大日志的协作┌─────────────────────────────────────────────────────────────┐ │ 1. 开启事务 │ │ └─► 分配 Rollback Segment准备 Undo Log 空间 │ ├─────────────────────────────────────────────────────────────┤ │ 2. 执行 UPDATE │ │ ├─► 记录修改前的旧值到 Undo LogBuffer Pool 中的 Undo 页│ │ ├─► 修改 Buffer Pool 中的数据页标记为脏页 │ │ └─► 将修改记录到 Redo Log Buffer │ ├─────────────────────────────────────────────────────────────┤ │ 3. 事务提交两阶段提交 │ │ ├─► 阶段 1Redo Log PREPARE刷盘 │ │ ├─► 写入 Binlog刷盘 │ │ └─► 阶段 2Redo Log COMMIT │ ├─────────────────────────────────────────────────────────────┤ │ 4. 后台异步刷脏页Checkpoint │ │ └─► 脏页刷盘后对应 Redo Log 空间可被重用 │ ├─────────────────────────────────────────────────────────────┤ │ 5. Purge 线程清理 Undo Log │ │ └─► 当无事务需要旧版本数据时清理过期 Undo Log │ └─────────────────────────────────────────────────────────────┘七、总结日志核心职责关键机制生产配置建议Redo Log保证已提交事务不丢失WAL、顺序写、循环覆盖innodb_flush_log_at_trx_commit1Undo Log支持回滚和 MVCC版本链、Purge 清理监控 History list length避免膨胀Binlog主从复制与数据恢复两阶段提交、ROW 格式binlog_formatROWsync_binlog1三大日志协同保障 ACID原子性AUndo Log 实现回滚一致性CRedo Undo Binlog 共同保证崩溃后的一致性状态隔离性IUndo Log 支持 MVCC 实现非锁定读持久性DRedo Log 保证已提交事务不丢失掌握这三大日志的底层原理是构建高可用、高性能 MySQL 数据库架构的基础
给机械臂设目标点，为什么还是解不出逆运动学？)
