爱睡觉.|

MuXinu

园龄:2年7个月粉丝:3关注:1

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_logfile0ib_logfile1 等。
  • 循环写
    • Redo Log 采用固定大小的 环形缓冲区,写满后循环覆盖。
    • 只保留最近的事务日志,旧的 redo log 只有在对应事务数据刷入磁盘(checkpoint)后才能被覆盖

工作原理

  1. 事务执行时,先将变更信息写入 Redo Log Buffer(内存)。
  2. 事务 COMMIT 时,先持久化 Redo Log 到磁盘(刷盘)。
  3. 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.000001mysql-bin.000002 等。
  • 存储格式
    • STATEMENT(基于 SQL 语句的 Binlog,SBR)
    • ROW(基于行的 Binlog,RBR,推荐)
    • MIXED(混合模式)

工作原理

  1. 事务执行时,先写 Binlog (顺序写,IO 开销小)
  2. 事务提交时,写入 Redo Log 并刷盘。
  3. 主从复制
    • 主库(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 读一致性、回滚 崩溃恢复 主从复制、增量备份

三者配合工作流程

  1. 事务开始
    • 记录 Undo Log(以支持回滚)。
  2. 事务执行
    • 变更操作写入 Redo Log Buffer(内存)。
  3. 事务提交前
    • Binlog 记录事务变更(SQL 语句或行变更)。
  4. 事务提交时
    • 先写 Binlog 并刷盘(持久化)。
    • 再写 Redo Log 并刷盘(确保崩溃恢复)。
  5. 事务回滚
    • 通过 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 中国大陆许可协议进行许可。

posted @   MuXinu  阅读(13)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 我与微信审核的“相爱相杀”看个人小程序副业
点击右上角即可分享
微信分享提示
评论
收藏
关注
推荐
深色
回顶
收起