MySQL日志

• MySQL 日志文件有哪些
• 介绍一下 binlog
• 有了 binlog 为什么还要 undolog redolog？

MySQL 日志文件有哪些

• 慢查询日志：sql 性能分析
• 错误日志：问题诊断
• general log：用于记录所有的 sql 语句
• binlog：记录所有修改数据库状态的 SQL 语句，以及每个语句的执行时间，用于主从复制和数据恢复
• redo log：保证事务持久性，记录对于 innodb 的每个写操作，用户崩溃恢复
• undo log：事务回滚

介绍一下 binlog

binlog 是一种二进制日志，在磁盘上记录数据库的所有修改操作

如果误删了数据，就可以使用 binlog 进行回退到误删之前的状态。

如果要搭建主从复制，就可以让从库定时读取主库的 binlog

MySQL 提供了三种格式的 binlog：Statement、Row 和 Mixed，分别对应 SQL 语句级别、行级别和混合级别，默认为行级别

从后缀名上来看，binlog 文件分为两类：以 .index 结尾的索引文件，以 .00000* 结尾的二进制日志文件

有了 binlog 为什么还要 undolog redolog？

日志类型	写入时间	作用	恢复能力	典型场景
redo log（重做日志）	事务提交前（物理页刷磁盘前）	保证 事务的持久性，崩溃恢复用	crash recovery	确保提交事务在系统崩溃后不丢失
undo log（回滚日志）	事务执行修改前	支持 事务回滚 和 MVCC 版本读取	回滚或快照读	回滚事务、实现一致性读（快照隔离）
binlog（二进制日志）	事务提交后	复制/审计/备份	主从同步或逻辑恢复	复制到从库、恢复历史操作、审计

binlog 属于 Server 层，与存储引擎无关，无法直接操作物理数据页。而 redo log 和 undo log 是 InnoDB 存储引擎实现 ACID 的基石

binlog 会记录整个 SQL 或行变化；redo log 是为了恢复「已提交但未刷盘」的数据，undo log 是为了撤销未提交的事务。

以一次事务更新为例：

事务开始（START TRANSACTION）

• 事务上下文在内存中创建
• 为事务分配 undo log 区域

undo log：准备记录修改前的数据，用于回滚和快照读

---

事务执行修改（UPDATE）

1. 生成 undo log
   • 保存修改前的旧值
   • 支持事务回滚和 MVCC 一致性读
2. 修改 buffer pool（内存页）
   • 数据页还在内存中，尚未刷盘
3. 生成 redo log（重做日志缓冲）
   • redo log 写入 重做日志缓冲区
   • 保证 crash 时可以恢复

---

事务提交（COMMIT）

1. redo log commit
   • redo log 中的事务 commit 标记写入磁盘（或日志缓冲刷盘）
   • 保证 Durability：事务提交后不会丢失
2. binlog 写入
   • binlog 是逻辑日志（记录 SQL 或行变化）
   • 写在事务提交后，保证逻辑一致性
   • 用于 主从复制、逻辑恢复、审计

---

数据页刷盘（Checkpoint）

• 数据页从 buffer pool 刷到磁盘
• redo log 依然保证 crash 恢复
• undo log 可以保留一段时间，用于快照读

---

5️⃣ crash 恢复场景

• 事务未提交：
  • redo log 没有 commit → 内存修改不持久
  • undo log 回滚事务 → 数据恢复到事务开始前
  • binlog 未写 → 不影响逻辑恢复
• 事务已提交：
  • redo log commit → 恢复已提交修改
  • binlog 写入 → 主从同步/审计
  • undo log 可以释放或继续用于 MVCC