MySQL的三大日志redolog,binlog,undolog

MySQL 的三大核心日志：redolog（重做日志）、binlog（二进制日志） 和 undolog（回滚日志），以及它们在事务处理和数据恢复中的作用。以下是要点汇总：

---

🧱 redo log（重做日志）

• 属于 InnoDB 存储引擎，用于崩溃恢复，确保数据的持久性。
• 数据修改会先记录到 redo log buffer，再根据策略刷盘到磁盘。
• 刷盘时机包括：
  • 事务提交
  • log buffer 空间不足
  • 检查点（Checkpoint）
  • 后台线程周期性刷新
  • 正常关闭服务器
• 参数 innodb_flush_log_at_trx_commit 控制刷盘策略：
  • 0：性能高但不安全，可能丢失最近 1 秒数据
  • 1：最安全，事务提交即刷盘（默认值）
  • 2：写入文件系统缓存，性能与安全性折中
• 日志文件组采用环形数组结构，由多个固定大小文件组成，MySQL 8.0.30 起使用 innodb_redo_log_capacity 统一配置。

---

📦 binlog（二进制日志）

• 属于 MySQL Server 层，用于数据同步、主从复制、备份恢复。
• 是逻辑日志，记录 SQL 原始语句或数据变更。
• 三种格式：
  • statement：记录 SQL 原文，可能导致同步不一致
  • row：记录具体数据变更，可靠性高但占空间
  • mixed：自动选择格式，兼顾性能与一致性
• 写入机制：
  • 事务执行时写入 binlog cache，提交时写入 binlog 文件
  • 参数 sync_binlog 控制刷盘频率，默认值为 1

---

🔁 两阶段提交机制

• 为了保证 redo log 与 binlog 的一致性，采用两阶段提交：
  • 第一步：写入 redo log 的 prepare 阶段
  • 第二步：写入 binlog 后，再提交 redo log 的 commit 阶段
• 若 binlog 写入失败，事务会回滚；若 redo log commit 失败但 binlog存在，事务仍可恢复。

---

🔙 undo log（回滚日志）

• 用于事务回滚和 MVCC（多版本并发控制），确保事务的原子性。
• 是逻辑日志，记录反向操作（如 DELETE 对应 INSERT）。
• undo log 也会被 redo log 持久化保护。
• 事务提交后，部分 undo log 会被清理，未清理的加入 history list，由后台线程 purge。
• undo log 以 segment（段）形式组织，便于并发管理。

---

📌 总结

• redo log 保证持久性，undo log 保证原子性，binlog 保证数据一致性与同步。
• 三者配合构成 MySQL 事务的完整日志体系，是高性能、高可靠数据库的基础。