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 事务的完整日志体系，是高性能、高可靠数据库的基础。
