在线 Java 面试刷题持续更新https://www.quanxiaoha.com/java-interview面试考察点日志体系理解面试官不仅仅是想知道三种日志的名字和定义更是想知道你是否理解 MySQL 的日志体系架构以及每种日志在整个事务生命周期中扮演的角色。崩溃恢复机制考察你是否清楚 MySQL 如何通过 redo log 保证持久性D、通过 undo log 保证原子性A和实现 MVCC以及 binlog 在主从复制中的作用。两阶段提交原理是否理解 redo log 和 binlog 的 两阶段提交 机制为什么需要这个机制来保证数据一致性。核心答案MySQL 中这三种日志各司其职核心区别如下对比维度redo logundo logbinlog归属层级InnoDB 引擎层InnoDB 引擎层MySQL Server 层核心作用崩溃恢复保证持久性事务回滚、MVCC保证原子性主从复制、数据备份写入方式循环写空间固定按事务写入追加写文件可配置内容形式物理日志在某某页修改了什么逻辑日志反向 SQL逻辑日志SQL 语句或行变更事务关联事务提交时刷盘事务执行中持续写事务提交时一次性写入一句话总结redo log 是 崩溃恢复的救命稻草undo log 是 后悔药的原料binlog 是 主从复制的信使。深度解析一、三种日志的架构位置img上图展示了 MySQL 三种日志的架构层级关系binlog位于Server 层所有存储引擎都可以使用。它是 MySQL 的 归档日志主要用于主从复制和数据备份恢复。以事件形式记录所有修改数据的 SQL 语句或行变更。redo log和undo log位于InnoDB 引擎层是 InnoDB 特有的。redo log 用于崩溃恢复采用 WALWrite-Ahead Logging机制undo log 用于事务回滚和 MVCC 实现。层级分离的意义正因为 binlog 在 Server 层redo log 在引擎层才需要 两阶段提交 来保证两者的一致性。二、redo log 详解img上图展示了 redo log 的循环写入机制循环写入redo log 不是无限追加的而是固定大小默认两个文件各 1GB循环使用。write pos记录当前写入位置checkpoint记录检查点位置。WAL 机制事务提交时先写 redo log顺序 I/O再异步刷脏页到数据文件随机 I/O。这样即使数据库崩溃也可以通过 redo log 恢复未刷盘的数据。刷盘时机事务提交时innodb_flush_log_at_trx_commit1最安全后台线程定时刷redo log 空间不足时关键配置-- 查看 redo log 配置 SHOW VARIABLES LIKE innodb_log%; -- innodb_log_file_size单个日志文件大小默认 48MB建议 1-2GB -- innodb_log_files_in_group日志文件数量默认 2 -- innodb_flush_log_at_trx_commit刷盘策略0/1/2建议 1三、undo log 详解img上图展示了 undo log 的两大核心作用事务回滚记录数据的 反向操作。UPDATE记录旧值DELETE记录整行INSERT记录主键。当事务回滚时用 undo log 中的信息恢复数据。MVCC 实现每行数据都有隐藏列trx_id事务 ID和roll_pointer回滚指针。通过roll_pointer找到 undo log 中的旧版本实现 读已提交 和 可重复读 隔离级别。undo log 存储位置-- MySQL 5.6 之前存储在共享表空间 ibdata1 -- MySQL 5.6可配置独立的 undo 表空间 SHOW VARIABLES LIKE innodb_undo%; -- innodb_undo_tablespacesundo 表空间数量 -- innodb_max_undo_log_sizeundo 表空间最大值 -- innodb_undo_log_truncate是否自动截断四、binlog 详解img上图展示了 binlog 在主从复制中的作用主库写入事务提交时将修改操作写入 binlog追加写入文件可配置滚动从库同步I/O Thread连接主库读取 binlog写入本地的 Relay Log中继日志SQL Thread读取 Relay Log重放 SQL 语句保持与主库数据一致binlog 三种格式格式记录内容优点缺点STATEMENTSQL 语句本身日志量小不确定函数可能导致不一致ROW行数据变更数据一致性最好日志量大MIXED混合模式兼顾两者复杂场景可能仍有问题-- 查看 binlog 配置 SHOW VARIABLES LIKE %binlog%; -- binlog_format日志格式推荐 ROW -- binlog_cache_size事务缓存大小 -- sync_binlog刷盘策略1 每次提交都刷盘最安全五、两阶段提交img上图展示了 redo log 和 binlog 的两阶段提交流程为什么需要两阶段提交因为 redo log 和 binlog 是两个独立的日志系统如果不协调可能出现redo log 写了但 binlog 没写 → 主库恢复后数据丢失从库没收到binlog 写了但 redo log 没写 → 主库恢复后数据回滚从库却收到了两阶段提交流程Prepare 阶段写 redo log标记为prepare状态Commit 阶段写 binlog然后写 redo log 标记为commit状态崩溃恢复如果崩溃时 redo log 处于prepare状态通过检查 binlog 是否完整来决定提交还是回滚。面试高频追问追问一redo log 为什么采用循环写而不是追加写循环写的目的是空间复用。redo log 只需要保留 从检查点到当前 的数据更早的日志对应的数据已经刷盘可以覆盖。追加写会导致磁盘空间无限增长不现实。追问二innodb_flush_log_at_trx_commit设为 0/1/2 有什么区别值行为安全性性能0每秒刷盘一次❌ 可能丢 1 秒数据最高1每次提交都刷盘✅ 不丢数据最安全较低2每次提交写入 OS 缓存每秒刷盘⚠️ 可能丢 1 秒数据中等**生产环境强烈推荐设为1**。追问三为什么 binlog 不能代替 redo log 做崩溃恢复binlog 是逻辑日志SQL 或行变更恢复时需要重新执行效率低redo log 是物理日志页修改恢复时直接应用效率高binlog 是追加写没有记录 哪些页已刷盘 的信息无法精确恢复追问四undo log 什么时候会被删除undo log 不会在事务提交后立即删除因为可能还有其他事务在用它做 MVCC 读。只有当所有活跃事务都不再需要这个 undo log时才会被 purge 线程清理。常见面试变体MySQL 是如何保证事务的 ACID 特性的redo log 和 binlog 有什么区别为什么要两阶段提交MVCC 是怎么实现的undo log 在其中扮演什么角色数据库崩溃后如何恢复数据记忆口诀三大日志定位redo log引擎层循环写崩溃恢复保持久undo log引擎层反向记回滚 MVCC 都靠它binlogServer 层追加写主从复制做备份两阶段提交先 prepare 后 commit中间写 binlog崩溃查状态总结redo log、undo log、binlog 是 MySQL 的三大核心日志。redo log 在 InnoDB 引擎层采用循环写的 WAL 机制保证崩溃恢复时的持久性undo log 记录反向操作支持事务回滚和MVCC实现binlog 在 Server 层追加写入用于主从复制和数据备份。三者通过 两阶段提交 保证一致性是 MySQL 高可用架构的基石。 欢迎加入小哈的星球你将获得:专属的项目实战多个项目 / 1v1 提问 /Java 学习路线 /学习打卡 / 每月赠书 / 社群讨论新项目《Spring AI 项目实战》正在更新中..., 基于 Spring AI Spring Boot 3.x JDK 21;《从零手撸仿小红书微服务架构》 已完结基于 Spring Cloud Alibaba Spring Boot 3.x JDK 17..., 点击查看项目介绍演示地址http://116.62.199.48:7070/《从零手撸前后端分离博客项目全栈开发》2期已完结,演示链接http://116.62.199.48/;专栏阅读地址https://www.quanxiaoha.com/column截止目前累计输出 100w 字讲解图 4013 张还在持续爆肝中..后续还会上新更多项目目标是将 Java 领域典型的项目都整一波如秒杀系统, 在线商城, IM 即时通讯Spring Cloud Alibaba 等等戳我加入学习解锁全部项目已有4500小伙伴加入1. 我的私密学习小圈子从0到1手撸企业实战项目~ 2. 字节二面什么是数据库死锁怎么解决修订版 3. 怎么阅读代码老司机总结的 6 个实用经验 4. OpenClaw到底能干嘛30个落地案例看完直接用最近面试BAT整理一份面试资料《Java面试BATJ通关手册》覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。 获取方式点“在看”关注公众号并回复 Java 领取更多内容陆续奉上。PS因公众号平台更改了推送规则如果不想错过内容记得读完点一下“在看”加个“星标”这样每次新文章推送才会第一时间出现在你的订阅列表里。 点“在看”支持小哈呀谢谢啦
腾讯二面:binlog、redolog 和 undolog 三大日志的区别?
发布时间:2026/6/4 4:26:48
在线 Java 面试刷题持续更新https://www.quanxiaoha.com/java-interview面试考察点日志体系理解面试官不仅仅是想知道三种日志的名字和定义更是想知道你是否理解 MySQL 的日志体系架构以及每种日志在整个事务生命周期中扮演的角色。崩溃恢复机制考察你是否清楚 MySQL 如何通过 redo log 保证持久性D、通过 undo log 保证原子性A和实现 MVCC以及 binlog 在主从复制中的作用。两阶段提交原理是否理解 redo log 和 binlog 的 两阶段提交 机制为什么需要这个机制来保证数据一致性。核心答案MySQL 中这三种日志各司其职核心区别如下对比维度redo logundo logbinlog归属层级InnoDB 引擎层InnoDB 引擎层MySQL Server 层核心作用崩溃恢复保证持久性事务回滚、MVCC保证原子性主从复制、数据备份写入方式循环写空间固定按事务写入追加写文件可配置内容形式物理日志在某某页修改了什么逻辑日志反向 SQL逻辑日志SQL 语句或行变更事务关联事务提交时刷盘事务执行中持续写事务提交时一次性写入一句话总结redo log 是 崩溃恢复的救命稻草undo log 是 后悔药的原料binlog 是 主从复制的信使。深度解析一、三种日志的架构位置img上图展示了 MySQL 三种日志的架构层级关系binlog位于Server 层所有存储引擎都可以使用。它是 MySQL 的 归档日志主要用于主从复制和数据备份恢复。以事件形式记录所有修改数据的 SQL 语句或行变更。redo log和undo log位于InnoDB 引擎层是 InnoDB 特有的。redo log 用于崩溃恢复采用 WALWrite-Ahead Logging机制undo log 用于事务回滚和 MVCC 实现。层级分离的意义正因为 binlog 在 Server 层redo log 在引擎层才需要 两阶段提交 来保证两者的一致性。二、redo log 详解img上图展示了 redo log 的循环写入机制循环写入redo log 不是无限追加的而是固定大小默认两个文件各 1GB循环使用。write pos记录当前写入位置checkpoint记录检查点位置。WAL 机制事务提交时先写 redo log顺序 I/O再异步刷脏页到数据文件随机 I/O。这样即使数据库崩溃也可以通过 redo log 恢复未刷盘的数据。刷盘时机事务提交时innodb_flush_log_at_trx_commit1最安全后台线程定时刷redo log 空间不足时关键配置-- 查看 redo log 配置 SHOW VARIABLES LIKE innodb_log%; -- innodb_log_file_size单个日志文件大小默认 48MB建议 1-2GB -- innodb_log_files_in_group日志文件数量默认 2 -- innodb_flush_log_at_trx_commit刷盘策略0/1/2建议 1三、undo log 详解img上图展示了 undo log 的两大核心作用事务回滚记录数据的 反向操作。UPDATE记录旧值DELETE记录整行INSERT记录主键。当事务回滚时用 undo log 中的信息恢复数据。MVCC 实现每行数据都有隐藏列trx_id事务 ID和roll_pointer回滚指针。通过roll_pointer找到 undo log 中的旧版本实现 读已提交 和 可重复读 隔离级别。undo log 存储位置-- MySQL 5.6 之前存储在共享表空间 ibdata1 -- MySQL 5.6可配置独立的 undo 表空间 SHOW VARIABLES LIKE innodb_undo%; -- innodb_undo_tablespacesundo 表空间数量 -- innodb_max_undo_log_sizeundo 表空间最大值 -- innodb_undo_log_truncate是否自动截断四、binlog 详解img上图展示了 binlog 在主从复制中的作用主库写入事务提交时将修改操作写入 binlog追加写入文件可配置滚动从库同步I/O Thread连接主库读取 binlog写入本地的 Relay Log中继日志SQL Thread读取 Relay Log重放 SQL 语句保持与主库数据一致binlog 三种格式格式记录内容优点缺点STATEMENTSQL 语句本身日志量小不确定函数可能导致不一致ROW行数据变更数据一致性最好日志量大MIXED混合模式兼顾两者复杂场景可能仍有问题-- 查看 binlog 配置 SHOW VARIABLES LIKE %binlog%; -- binlog_format日志格式推荐 ROW -- binlog_cache_size事务缓存大小 -- sync_binlog刷盘策略1 每次提交都刷盘最安全五、两阶段提交img上图展示了 redo log 和 binlog 的两阶段提交流程为什么需要两阶段提交因为 redo log 和 binlog 是两个独立的日志系统如果不协调可能出现redo log 写了但 binlog 没写 → 主库恢复后数据丢失从库没收到binlog 写了但 redo log 没写 → 主库恢复后数据回滚从库却收到了两阶段提交流程Prepare 阶段写 redo log标记为prepare状态Commit 阶段写 binlog然后写 redo log 标记为commit状态崩溃恢复如果崩溃时 redo log 处于prepare状态通过检查 binlog 是否完整来决定提交还是回滚。面试高频追问追问一redo log 为什么采用循环写而不是追加写循环写的目的是空间复用。redo log 只需要保留 从检查点到当前 的数据更早的日志对应的数据已经刷盘可以覆盖。追加写会导致磁盘空间无限增长不现实。追问二innodb_flush_log_at_trx_commit设为 0/1/2 有什么区别值行为安全性性能0每秒刷盘一次❌ 可能丢 1 秒数据最高1每次提交都刷盘✅ 不丢数据最安全较低2每次提交写入 OS 缓存每秒刷盘⚠️ 可能丢 1 秒数据中等**生产环境强烈推荐设为1**。追问三为什么 binlog 不能代替 redo log 做崩溃恢复binlog 是逻辑日志SQL 或行变更恢复时需要重新执行效率低redo log 是物理日志页修改恢复时直接应用效率高binlog 是追加写没有记录 哪些页已刷盘 的信息无法精确恢复追问四undo log 什么时候会被删除undo log 不会在事务提交后立即删除因为可能还有其他事务在用它做 MVCC 读。只有当所有活跃事务都不再需要这个 undo log时才会被 purge 线程清理。常见面试变体MySQL 是如何保证事务的 ACID 特性的redo log 和 binlog 有什么区别为什么要两阶段提交MVCC 是怎么实现的undo log 在其中扮演什么角色数据库崩溃后如何恢复数据记忆口诀三大日志定位redo log引擎层循环写崩溃恢复保持久undo log引擎层反向记回滚 MVCC 都靠它binlogServer 层追加写主从复制做备份两阶段提交先 prepare 后 commit中间写 binlog崩溃查状态总结redo log、undo log、binlog 是 MySQL 的三大核心日志。redo log 在 InnoDB 引擎层采用循环写的 WAL 机制保证崩溃恢复时的持久性undo log 记录反向操作支持事务回滚和MVCC实现binlog 在 Server 层追加写入用于主从复制和数据备份。三者通过 两阶段提交 保证一致性是 MySQL 高可用架构的基石。 欢迎加入小哈的星球你将获得:专属的项目实战多个项目 / 1v1 提问 /Java 学习路线 /学习打卡 / 每月赠书 / 社群讨论新项目《Spring AI 项目实战》正在更新中..., 基于 Spring AI Spring Boot 3.x JDK 21;《从零手撸仿小红书微服务架构》 已完结基于 Spring Cloud Alibaba Spring Boot 3.x JDK 17..., 点击查看项目介绍演示地址http://116.62.199.48:7070/《从零手撸前后端分离博客项目全栈开发》2期已完结,演示链接http://116.62.199.48/;专栏阅读地址https://www.quanxiaoha.com/column截止目前累计输出 100w 字讲解图 4013 张还在持续爆肝中..后续还会上新更多项目目标是将 Java 领域典型的项目都整一波如秒杀系统, 在线商城, IM 即时通讯Spring Cloud Alibaba 等等戳我加入学习解锁全部项目已有4500小伙伴加入1. 我的私密学习小圈子从0到1手撸企业实战项目~ 2. 字节二面什么是数据库死锁怎么解决修订版 3. 怎么阅读代码老司机总结的 6 个实用经验 4. OpenClaw到底能干嘛30个落地案例看完直接用最近面试BAT整理一份面试资料《Java面试BATJ通关手册》覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。 获取方式点“在看”关注公众号并回复 Java 领取更多内容陆续奉上。PS因公众号平台更改了推送规则如果不想错过内容记得读完点一下“在看”加个“星标”这样每次新文章推送才会第一时间出现在你的订阅列表里。 点“在看”支持小哈呀谢谢啦