Java高频面试：在Mysql数据库中 bin log 和 redo log 有什么区别？为什么？

张开发
• 2026/4/10 7:50:16 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

Java高频面试：在Mysql数据库中 bin log 和 redo log 有什么区别？为什么？
面试官 能详细解释一下MySQL中binlog和redo log的主要区别吗它们在数据库运行中各自扮演什么角色面试者binlog的话主要是做主从同步redolog是为了数据不会丢失。宕机的时候能找到丢失的数据。面试官他们底层有个2阶段提交来保证2个日志的原子性你能给我讲下为什么么面试者呃。。。面试官: 首先它们俩的定位和用途完全不同。binlog是MySQL Server层的归档日志和复制日志。它记录的是逻辑操作比如“在用户表插入了一条ID1的数据”。不管底层用的是InnoDB还是其他存储引擎只要是数据库的变更它都记录。所以它的核心任务是数据归档、按时间点恢复以及最重要的——主从复制。可以说它是为了数据流转和备份而生的。redo log是InnoDB存储引擎层的重做日志。它记录的是物理修改描述的是“在表空间A的第100号数据页偏移量200的位置把数据从‘ABC’改成了‘XYZ’”。它的核心任务就一个确保事务的持久性实现崩溃恢复。当数据库异常重启InnoDB就靠它来把数据恢复到崩溃前的状态。它是为了保证数据本身不丢而设计的。一个管“复制和归档”一个管“崩溃恢复”看起来各司其职对吧但MySQL为了保证主从数据的绝对一致性必须让它们俩协同工作这就引出了最关键的问题原子性。为什么必须保证这两个日志的原子性呢我们来看两个致命的“如果”第一种情况假设一个事务提交时binlog写成功了但redo log没写成功接着数据库宕机了。从库那边因为它拿到了完整的binlog所以同步到了这个事务的变更。主库这边重启后因为redo log不完整无法恢复这个事务数据就丢了。结果主库的数据落后于从库主从不一致。第二种情况反过来redo log写成功了但binlog写失败了。主库这边重启后能根据redo log成功恢复数据。从库那边因为没收到这个事务的binlog完全不知道发生了什么。结果主库的数据领先于从库还是主从不一致。所以MySQL的解决方案是引入了一个经典的两阶段提交2PC协议。简单来说就是把一个事务的提交拆成“准备”和“提交”两步让binlog和redo log在这两个阶段“对表”确保它们在任何时候都处在一致的状态。

更多文章