刚才聊完了 MySQL 的索引很多兄弟可能会觉得“只要索引建好了数据库不就稳了吗”其实不然。索引决定了你查得快不快而日志Log则决定了你的数据稳不稳尤其是在断电、宕机这种极端情况下数据能不能找回来全靠它们。今天学长就来带大家深度拆解一下 MySQL 的四大核心日志redo log、undo log、binlog和relay log。咱们不聊虚的概念直接看它们在实战中到底是怎么配合的。一、 redo log重做日志掉电也不怕的“保护神”redo log是物理日志由 InnoDB 存储引擎生成。它的核心作用只有两个字可靠。1. 为什么需要它数据库的数据是存在磁盘上的。如果每次改数据都直接写磁盘那随机 I/O 的性能开销会让你怀疑人生。所以 MySQL 引入了WALWrite-ahead logging机制事务提交前先写日志再写磁盘。2. 它是怎么工作的顺序写入相比于改数据时的随机 I/Oredo log 是追加写入的性能极高。Checkpoint 机制它不会无限增长而是定期将内存中的脏数据刷到磁盘并记录 LSN日志序列号。Crash Recovery如果数据库突然掉电重启后 InnoDB 会读取 redo log 里的记录把还没写进磁盘的数据“重做”一遍保证了事务的持久性。二、 undo log回滚日志事务的“后悔药”如果说 redo log 记录的是“我要做什么”那undo log记录的就是“我之前长什么样”。1. 保证原子性当你执行一个失败的事务或者手动执行ROLLBACK时InnoDB 就会根据 undo log 里的记录把数据改回修改前的样子从而保证事务的原子性。2. 实现 MVCC多版本并发控制这是面试的高频点。InnoDB 的 MVCC 并不是真的存了多个数据副本而是通过ReadView undo log链条实现的。当你查询某个快照版本时系统会顺着 undo log 往前找拼凑出那个时间点的数据模样。三、 binlog归档日志Server 层的“流水账”binlog是逻辑日志属于 MySQL Server 层生成的日志所有引擎都能用。1. 它的功能主从复制这是 binlog 最常用的场景Master 把变动记入 binlogSlave 同步过去执行。数据备份/恢复如果你不小心drop了一张表可以通过全量备份加上 binlog 里的增量记录把数据追回来。2. 核心细节二阶段提交Two-phase Commit为了保证 redo log引擎层和 binlogServer 层的数据一致性MySQL 采用了一个复杂的二阶段提交过程prepare 阶段写 redo log状态设为 prepare并持久化。commit 阶段写 binlog 并持久化然后把 redo log 的状态改为 commit。崩溃恢复逻辑如果系统在中间崩溃了重启后会根据 binlog 里的 XID 来判断如果 binlog 完整即便 redo log 是 prepare 状态也会选择提交。四、 relay log中继日志主从同步的“搬运工”这个日志只存在于Slave从库上。在主从复制场景下Slave 的 I/O 线程把 Master 的 binlog 拷贝过来存在本地就成了 relay log。随后SQL 线程读取 relay log 并在从库上重放从而实现数据同步。五、 总结四大日志的功能对比为了方便大家记忆我总结了这张表日志类型所属层级记录内容核心作用事务特性redo log存储引擎 (InnoDB)物理记录页的改动崩溃恢复、防止掉电数据丢失持久性undo log存储引擎 (InnoDB)逻辑记录改动前的旧值事务回滚、MVCC原子性binlogServer 层逻辑记录SQL 或原始值数据备份、主从复制-relay log从库专用拷贝自 Master 的 binlog作为中转站实现主从同步-在实际面试中面试官最爱问的其实是“binlog 和 redo log 有什么区别”或者是“二阶段提交是怎么保证一致性的”。理解了日志你就能明白为什么 MySQL 的写入性能可以这么高同时还能在宕机时面不改色地找回数据。除了这些还有像慢查询日志这种需要手动开启的工具它记录了执行时间超过阈值的 SQL是咱们进行性能优化的头号利器。