MySQL中的三种日志(Undo Log、Redo Log和Binlog)
MySQL 主要有三种重要的日志机制:Undo Log、Redo Log 和 Binlog,它们在数据库事务管理、崩溃恢复和数据持久化等方面发挥重要作用。下面详细介绍这三种日志的作用、存储方式和工作原理。
1. Undo Log(回滚日志)
作用
- 主要用于 事务回滚,保证事务的原子性(Atomicity)。
- 还用于 MVCC(多版本并发控制),实现一致性读(例如
REPEATABLE READ
隔离级别下的快照读)。
存储方式
- 存储位置:在 InnoDB 引擎中,
Undo Log
存储在 共享表空间(ibdata) 或 独立 Undo Tablespace 中。 - 存储结构:
- 逻辑日志,记录事务修改前的数据(旧值),以便回滚时恢复。
- 由多个 undo 记录 组成,每个
undo 记录
包含一条 SQL 操作的 反向操作。
工作原理
- 事务开始 时,MySQL 记录 Undo Log。
- 事务提交 后,Undo Log 仍然保留一段时间(用于 MVCC),但之后可以被清理。
- 事务回滚 时,InnoDB 通过 Undo Log 逐步撤销事务修改,使数据库恢复到事务开始前的状态。
示例
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- 事务未提交,Undo Log 记录旧的 balance 值
ROLLBACK; -- 事务回滚,恢复到原 balance
2. Redo Log(重做日志)
作用
- 主要用于 崩溃恢复,保证事务的持久性(Durability)。
- 解决了WAL(Write-Ahead Logging,预写日志)机制,即 先写日志再写磁盘,确保即使宕机,已提交事务的数据不会丢失。
存储方式
- 存储位置:存储在 InnoDB 的 redo log buffer(内存) 和 redo log file(磁盘)中,文件位于
ib_logfile0
、ib_logfile1
等。 - 循环写:
- Redo Log 采用固定大小的 环形缓冲区,写满后循环覆盖。
- 只保留最近的事务日志,旧的 redo log 只有在对应事务数据刷入磁盘(checkpoint)后才能被覆盖。
工作原理
- 事务执行时,先将变更信息写入 Redo Log Buffer(内存)。
- 事务
COMMIT
时,先持久化 Redo Log 到磁盘(刷盘)。 - MySQL 崩溃后,可以通过 Redo Log 重做已提交的事务,确保事务持久化。
示例
START TRANSACTION;
UPDATE orders SET status = 'shipped' WHERE order_id = 1001;
COMMIT; -- 事务提交时,写入 Redo Log
即使 MySQL 在 COMMIT
之后宕机,数据仍然可以通过 Redo Log 恢复。
3. Binlog(归档日志)
作用
- 主要用于数据库备份、主从复制、数据恢复。
- 记录所有修改数据的 SQL 语句(逻辑日志),而不是物理页的变更。
- 不仅 InnoDB 使用,MyISAM 等引擎也可以使用 Binlog。
存储方式
- 存储位置:存储在 MySQL Server 层,文件名一般是
mysql-bin.000001
,mysql-bin.000002
等。 - 存储格式:
- STATEMENT(基于 SQL 语句的 Binlog,SBR)
- ROW(基于行的 Binlog,RBR,推荐)
- MIXED(混合模式)
工作原理
- 事务执行时,先写 Binlog (顺序写,IO 开销小)。
- 事务提交时,写入 Redo Log 并刷盘。
- 主从复制:
- 主库(Master)记录 Binlog,并发送给从库(Slave)。
- 从库解析 Binlog 并执行相同的 SQL 语句,保持数据同步。
示例
SET GLOBAL binlog_format = 'ROW'; -- 配置 Binlog 为行格式(RBR)
SHOW BINARY LOGS; -- 查看 Binlog 日志
Binlog 主要用于 主从复制 和 数据恢复。
三者区别总结
特性 | Undo Log | Redo Log | Binlog |
---|---|---|---|
作用 | 事务回滚、MVCC | 崩溃恢复、保证事务持久性 | 备份、恢复、主从复制 |
存储位置 | InnoDB | InnoDB | MySQL Server 层 |
存储方式 | 逻辑日志 | 物理日志(页级) | 逻辑日志(SQL 语句或行变更) |
何时写入 | 事务修改数据时 | 事务执行时 | 事务提交前 |
何时清理 | 事务回滚或 Purge | Checkpoint 后 | 手动清理或自动切换 |
应用场景 | MVCC 读一致性、回滚 | 崩溃恢复 | 主从复制、增量备份 |
三者配合工作流程
- 事务开始:
- 记录
Undo Log
(以支持回滚)。
- 记录
- 事务执行:
- 变更操作写入 Redo Log Buffer(内存)。
- 事务提交前:
Binlog
记录事务变更(SQL 语句或行变更)。
- 事务提交时:
- 先写 Binlog 并刷盘(持久化)。
- 再写 Redo Log 并刷盘(确保崩溃恢复)。
- 事务回滚:
- 通过
Undo Log
恢复数据。
- 通过
WAL 机制(Write-Ahead Logging) 规定:先写日志(Redo Log),再提交事务,最后落盘数据,这保证了事务的原子性和持久性。
总结
- Undo Log:用于事务回滚和 MVCC,保证事务的原子性。
- Redo Log:用于崩溃恢复,保证事务的持久性(WAL)。
- Binlog:用于主从复制、增量备份、数据恢复,支持跨存储引擎。
三者结合,确保了 MySQL 的 事务完整性、崩溃恢复能力、数据复制与备份能力。
本文作者:MuXinu
本文链接:https://www.cnblogs.com/MuXinu/p/18714045
版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 我与微信审核的“相爱相杀”看个人小程序副业