MySQL 中的 undo log、redo log、binlog 是三类核心日志，核心区别在于作用目标、功能用途和使用场景完全不同，分别保障事务原子性、数据持久性和数据一致性/恢复能力，具体差异如下：
1. redo log（重做日志）
核心作用：保障事务持久性（ACID 中的 D），防止数据库崩溃后未刷盘的数据丢失。
工作原理：
1.事务执行时，先将数据修改操作记录到 redo log（内存 + 磁盘文件），再更新内存中的数据（Buffer Pool）。
2.无需等待数据立即写入磁盘文件，由后台线程按“ checkpoint ”机制异步将 redo log 中的操作刷到磁盘数据文件。
3.若数据库崩溃，重启后可通过 redo log 重放未刷盘的操作，恢复数据。
关键特点：
物理日志：记录“某数据页的某位置修改为某值”（如“表 t1 的页 100 中偏移量 50 的值改为 10”）。
循环写：日志文件固定大小，写满后覆盖旧内容，不无限增长。
仅在 InnoDB 存储引擎中存在（属于引擎层日志）。
2. undo log（回滚日志）
核心作用：保障事务原子性（ACID 中的 A），支持事务回滚和 MVCC（多版本并发控制）。
工作原理：
1.事务执行修改操作前，先将数据的“旧值”记录到 undo log（如“修改前某行数据值为 5”）。
2.若事务执行失败（或调用 ROLLBACK），通过 undo log 恢复数据到修改前的状态，实现“回滚”。
3.同时，undo log 会作为 MVCC 的“版本链”，供读操作（如 SELECT）获取历史数据，避免读写冲突。
关键特点：
逻辑日志：记录“反向操作”（如“插入一条数据”对应“删除该数据”的 undo 记录）。
可回收：事务提交后，undo log 不会立即删除，待没有读操作依赖其版本链时，由后台线程清理。
仅在 InnoDB 存储引擎中存在（属于引擎层日志）。
3. binlog（二进制日志）
核心作用：记录所有数据修改操作，用于主从复制和数据时间点恢复，保障集群数据一致性和灾难恢复能力。
工作原理：
1.事务提交时，将事务中的所有修改操作（增删改）以“事件”形式记录到 binlog。
2.主从复制时，从库读取主库的 binlog 并执行，实现数据同步；
3.数据恢复时，可通过 binlog 重放指定时间段的操作，将数据恢复到误操作前的状态。
关键特点：
逻辑日志：记录“操作语句的逻辑”（如“给表 t1 中 id=1 的行的 age 加 1”）。
追加写：日志文件按大小或时间切割，不会覆盖旧内容，可长期保存。
属于 MySQL 服务器层日志（所有存储引擎都支持，如 MyISAM、InnoDB）。
三者核心区别总结表
| 维度 | redo log | undo log | binlog |
|---|---|---|---|
| 归属层级 | InnoDB 引擎层 | InnoDB 引擎层 | MySQL 服务器层 |
| 核心目标 | 保障事务持久性 | 保障事务原子性 + 支持 MVCC | 主从复制 + 时间点恢复 |
| 日志类型 | 物理日志（数据页修改） | 逻辑日志（反向操作） | 逻辑日志（操作事件） |
| 写入时机 | 事务执行中实时写入 | 事务执行前写入 | 事务提交后写入 |
| 生命周期 | 循环写（写满覆盖） | 提交后可回收 | 追加写（长期保存） |
| 是否跨引擎 | 仅 InnoDB 支持 | 仅 InnoDB 支持 | 所有引擎支持 |
