只要你用开源关系型数据库写过业务就一定绕不开这三样东西——undo log、redo log、bin log。很多人能把“事务四大特性”“ACID”背得滚瓜烂熟但真被问到“一条 UPDATE 执行过程中这三本日志各自记了什么、为什么提交的时候非要搞一个二阶段提交”就很容易卡壳。这很正常因为日志是数据库最底层的那套机制平时你写 CRUD 根本看不见它可它恰恰决定了三件要命的事事务能不能回滚、断电后数据丢不丢、主从之间对不对得上账。这篇文章我把这三本日志里里外外拆开讲一遍再带你完整走一次事务提交的全程重点讲清楚二阶段提交为什么存在、崩溃恢复时是怎么靠日志状态来“断案”的。适合对数据库原理有兴趣的开发者、刚入手 DBA 方向的朋友以及那些已经被主从数据不一致、误删数据恢复这类问题折磨过的人。看完以后你再看“双 1 配置”“组提交”“崩溃恢复”这些词就不会再觉得它们是玄学了。1. 三大日志的分工先把各自的一亩三分地划清楚1.1 undo log藏在身后的旧账本一切回滚的底气undo log 属于数据库引擎层。它在事务执行期间把每次修改前的旧值记录下来。比如你把某行数据的状态从“待支付”改成了“已支付”真正动手改数据之前引擎会先往 undo log 里存一条“这行原来的值是待支付”。如果事务在中途出错要执行回滚就把这些旧值重新写回去。这个过程你可以理解成你给墙刷漆之前先拍一张旧墙面的照片。刷坏了想恢复原样照着照片重新刷一遍就行。undo log 就是那张“照片”。但 undo 的用途不止回滚。你可能用过可重复读隔离级别下的多版本并发控制它是靠什么来构造老版本的靠的就是 undo log。事务开启并创建 read view 之后如果某个数据行被别的事务改了当前事务要去读旧版本时引擎会顺着当前版本的 undo 指针在历史上找到符合可见性规则的版本。这个版本数据不是存在数据页里的而是通过 undo 逐条还原出来的。undo log 本身也分两类insert undo 和 update undo。插入操作产生的 undo 相对简单因为插入的行只有自己能看到回滚时直接删除即可这类 undo 在事务提交后就可以直接清理。而更新和删除产生的 undo 要复杂一些因为可能还有别的事务在读取旧版本提交后也不能马上清掉要等所有可能的读取者都结束后由后台的 purge 线程逐步清理。这也是为什么有时候一张表频繁更新undo 文件会偏大甚至出现版本堆积的后果。1.2 redo log断电之后那根救命稻草redo log 同样属于引擎层但它和 undo log 完全是两个方向。undo 记的是“旧值”redo 记的是“新值”undo 用来回滚redo 用来重做。redo log 记录的是物理层面的修改痕迹哪个表空间、哪个数据页、在页面哪个偏移量处、写入了什么内容。说白了它不是记你执行了什么 SQL而是记录这次修改在磁盘页面上到底动了哪些地方。为什么需要它这就得从数据库的缓存机制说起。每次写操作不能真的直接去改磁盘文件性能会差到没法用。引擎的做法是先改内存里的缓冲池数据页然后把这个页标记成脏页等到合适的时机再统一刷到磁盘。这就带来一个风险如果事务提交了、内存里的数据还没来得及刷盘这时候机器突然断电内存内容全没了这一笔已提交的数据就丢了。为了解决这个问题业界普遍使用 WAL 机制也就是先写日志再写数据。事务提交时引擎先把这条修改对应的 redo log 刷到磁盘上这个消息一落盘事务就算稳了。哪怕数据页还没刷盘未来某天系统崩溃重启引擎也会扫描 redo log把那些已提交但尚未落盘的修改重新执行一遍从而保证了持久性。redo log 还有一个特点它是固定大小、循环利用的。你可以把它想象成环形剧场里的黑板旧内容被新内容不断覆盖。引擎内部通过 checkpoint 机制标记哪些脏页已经刷盘刷盘之后对应的 redo 就不再有价值可以被后续日志覆盖。如果 redo 写满了而脏页迟迟没刷下去系统就会强制触发刷盘动作。1.3 bin log站在服务层的全程录像bin log 跟前面两个完全不在一个层级。undo 和 redo 是存储引擎自己维护的bin log 则是数据库实例的服务层产生的和用哪个存储引擎没有直接关系。它记录的内容是“事务执行后产生的逻辑结果”可以是执行过的 SQL 语句也可以是每一行数据的具体变更看你的记录格式配置。bin log 的用途非常明确平时你遇到的基于日志的主从复制从库就是用主库传来的 bin log 来重放数据变更。做基于时间点、基于位置的数据恢复也是拿全量备份加上后续 bin log 一起回放。此外如果你想审计某段时间内哪些表被改过同样可以从 bin log 里翻出证据。它的生命周期和 redo 完全不同。bin log 是按文件滚动归档的一个文件写满了就换下一个你可以根据保留策略留下很多历史上的 bin log而不是循环覆盖。也正因为如此bin log 文件积累多了之后它本身也占磁盘日常运维里清理过期 bin log 是一个标准动作。三种日志放一起对比职责差异就很明显了对比项undo logredo logbin log所在层级引擎层引擎层服务层记录内容修改前的旧值页面物理修改逻辑变更结果主要用途回滚、多版本控制崩溃恢复、持久性保证主从复制、恢复、审计生命周期事务结束后可逐步清理循环覆盖、受 checkpoint 控制文件滚动归档、长期保留记录格式内部格式内部物理格式statement / row / mixed2. 为什么要二阶段提交两本日志对不上账的后果2.1 一次写操作在三本日志里的完整顺序事务执行过程中正常流程是这样的先为事务生成 undo log记录旧值然后在内存页里应用修改并生成对应的 redo log此时数据页已经变了但 redo 和 bin log 都还没有落到最终状态。等到事务提交的那一刻才是真正较劲的时候。提交动作大体分成三步首先把该事务的 redo log 刷入磁盘并标记为 prepare 状态然后写入 bin log 并落盘最后把 redo log 中的事务标记为 commit。这里最关键的一点在于 redo 的 prepare 状态出现在 bin log 写入之前而 redo 的 commit 状态出现在 bin log 写入之后。正是这一步构成了所谓的二阶段提交。你可能要问为什么提交一个事务要搞得这么麻烦直接把 redo 刷盘、打个 commit 完事不就行了吗问题在于光引擎自己点头还不够bin log 也必须跟着点头。两个日志分布在不同的模块它们各自记录各自的不可能天然保持一致。任何一个先写入、任何一个后写入崩溃恢复时都可能出现“引擎说提交了bin log 却没有”或者“bin log 有了引擎却没提交”的尴尬局面。2.2 假设没有二阶段提交会发生什么为了理解二阶段提交存在的意义不妨看看如果不用它会出现哪些问题。先设想一种方案先写 redo 并提交再写 bin log。主库上引擎已经把事务提交了数据也稳了但这时候机器崩了bin log 还没写出去。等主库恢复数据没有丢可 bin log 里压根没有这个事务的记录。后面的从库拿不到这条变更数据就和主库不一致。更麻烦的是如果你以后需要拿 bin log 做恢复这条事务也丢了主库和从库之间的账永远对不上。再设想另一种方案先写 bin log再提交 redo。如果 bin log 已经落盘、事务却被回滚了那么从库会把这条变更重放出来可主库自己反而没有这条数据。这就更离谱了业务上从库多出了一部分数据主从不一致问题的方向反了过来。所以你会发现单靠调整先后顺序解决不了问题。必须要有一个机制让 redo 和 bin log 要么一起生效要么一起不生效不能出现中间状态。二阶段提交正是专门为这个原子性问题设计的。2.3 先 prepare 后 commit一场两阶段的“投票”二阶段提交的思路不复杂就是给事务提交人为地划出两个阶段。第一阶段是准备阶段。引擎把 redo log 刷到磁盘并标记为该事务处于 prepare 状态同时把事务的 XID 写进日志。这个状态含义是引擎已经准备好提交事务的修改已经持久化到了 redo 里只等最后一声令下。第二阶段是提交阶段。服务层把该事务的 bin log 写入并落盘然后让引擎把 redo 里的这个事务标记成 commit。从这一刻起事务才算真正提交完成客户端才会收到成功的响应。注意一个细节commit 标记本身并不需要立刻刷盘。它只是修改内存中 redo 日志块的状态真正落盘可以顺延到后续刷盘时机。这是因为引擎判断一个事务是否有效依据的是 prepare 阶段就已经持久化的 redo 内容commit 标记只是用来标记“这个事务已经最终定案”。3. 二阶段提交的完整执行链路与崩溃恢复断案逻辑3.1 正常提交的分步拆解把二阶段提交放到实际操作里去一条事务从执行到提交大致会经历下面这些步骤。当你发起一条 UPDATE 语句时事务已经隐式或显式地开启。引擎先写 undo 日志记录修改前的旧值接着在缓冲池中更新对应数据页页面变为脏页同时生成 redo 日志记录这次页面修改。这个阶段里redo 可能还在内存的日志缓冲区里并没有立刻落盘。提交时刻到来第一阶段启动。引擎把事务产生的 redo 日志从日志缓冲区写入系统表空间下的 redo 日志文件并调用系统调用完成落盘使它在断电后依然存活。此时日志中的事务标记为 prepare同时写入事务的 XID。紧接着第二阶段开始。服务层把事务的 bin log 写入 bin log 文件。同样地bin log 也不是直接落盘的事务产生的日志事件先进 bin log 缓冲区提交时统一写入文件并执行落盘。这一步走完bin log 里已经完整记录了这个事务。最后一步引擎把 redo 日志里对应的这个事务标记为 commit。这个动作完成后事务才算真正结束。整个提交过程中undo、redo、bin log 三本日志的状态才算达成一致。这里有一个工程上的优化很重要叫组提交。如果每一个事务提交都要刷盘一次高并发下的 fsync 次数会非常恐怖性能直线下降。组提交的思路是把一批同时到达提交阶段的事务攒在一起用一次刷盘操作同时落盘多个事务的 redo 和 bin log。这样既能保证持久性又能把磁盘写入次数降下来。很多线上数据库把组提交调好后即使开着最安全的双 1 配置性能也可以接受。3.2 崩溃之后谁说了算二阶段提交的真正价值体现在崩溃恢复时。数据库启动时引擎会扫描 redo log找出所有没有完成提交动作的事务。这里只会有两种情况一种是在 prepare 状态下就没有后续了另一种是已经打上了 commit 标记。先看已经标记 commit 的事务这个没有争议直接判定为已提交恢复时重放它的修改。真正需要断案的是那些停在 prepare 状态的事务。它们到底是提交了还是没提交只看 redo 自己无法给出答案因为二阶段提交里prepare 状态只是准备信号最终是否提交取决于 bin log 有没有写入完成。这时候恢复流程会拿出事务写在 redo 里的 XID去 bin log 里查找这个事务是否存在。如果 bin log 里能找到这个 XID而且对应的事务事件是完整的那说明第二阶段已经走过只是 commit 标记还没刷盘而已。此时系统会补齐 commit 标记事务判定为已提交。反之如果 bin log 里根本没有这个事务或者事务事件不完整比如只写了一半机器就崩了那么这个事务判定为未提交执行回滚。你可能会好奇为什么偏偏拿 bin log 当判断依据因为 bin log 是数据同步的源头主从复制、外部数据同步都靠它。只要 bin log 里出现了某个事务那么从库、下游系统都有可能已经持有这份数据。主库恢复时如果不承认这个事务就会造成主库和从库之间的数据分歧。反过来bin log 没有完整写出的事务从库不会看到主库也就不该保留。所以用 bin log 是否完整作为最终提交的判据能保证所有数据管道各方看得到同一份“最终决议”。3.3 手工模拟崩溃点你会看到什么为了把恢复逻辑讲透我模拟一个事务提交过程中的三个崩溃瞬间。假设事务 T 已经执行完 UPDATE正在走提交流程。崩溃时刻redo 状态bin log 状态恢复动作最终结果时刻 Aprepare 刷盘后、写 binlog 前T 标记为 prepare含 XID没有 T 的完整事务找到 prepare 事务binlog 无对应 XID回滚事务未提交数据回滚时刻 Bbinlog 写入完成落盘后、commit 标记前T 标记为 prepare含 XIDT 的完整事务已存在含 XID找到 prepare 事务binlog 有完整 XID补齐 commit事务已提交数据保留时刻 Credo commit 标记已写入T 标记为 commitT 已存在扫描到 commit 标记无需额外判断事务已提交数据保留这张表基本就是崩溃恢复逻辑的全部。你不需要背更多的规则三行就够。真正要留意的是 bin log 的“完整”这两个字到底怎么判断。一个事务在 bin log 里以 BEGIN 事件开头以 XID 事件或 COMMIT 事件结尾。如果文件里只出现了 BEGIN、中间的一堆变更事件但没有结尾标记就说明写一半崩了要按未提交处理。4. 常见问题与实战排查技巧把三本日志变成排查利器4.1 “双 1”配置真的任何时候都必须吗常在数据库文档里看到两个参数引擎层的 innodb_flush_log_at_trx_commit 和服务层的 sync_binlog。两个都设为 1 就是所谓的“双 1”这是数据安全级别最高的配置但很多人不清楚它们分别控制什么以及调低之后到底会有什么后果。innodb_flush_log_at_trx_commit 设置为 1 时每个事务提交都会把 redo log 刷盘保证事务不会因数据库进程崩溃或操作系统崩溃而丢失。设为 0 时redo 只停留在内存日志缓冲区由后台线程定频刷盘性能最好但数据库进程崩溃就会丢失最近的一批已提交事务。设为 2 时提交时把 redo 写入操作系统的 page cache但不等它落盘。这种配置下数据库进程崩溃不会丢数据因为数据还在操作系统缓存里只有操作系统或整机断电才会丢。sync_binlog 同理。设为 1 时每个事务提交都刷盘 bin log设为 0 或大于 1 的值时bin log 落盘频率降低性能更好但如果系统崩溃bin log 文件可能缺失一部分事务。同样bin log 一旦缺失那部分数据无法从 bin log 回放主从节点之间也会出现分歧。实际选型时我的建议是交易、支付、订单这类核心链路老老实实保持双 1别动。日志类的、允许丢失几十秒数据的业务可以尝试组合调整但一定要把风险写在纸上让业务方明确知道什么场景下会丢数。下面这张表是不同组合下的风险表现redo 参数bin log 参数数据库进程崩溃操作系统崩溃主从一致性11不丢已提交事务不丢已提交事务无不一致窗口21不丢已提交事务可能丢最近未落盘事务可能不一致10不丢已提交事务bin log 缺失部分事务可能不一致20不丢已提交事务两边都可能丢失明显不一致窗口需要特别注意bin log 参数为 0 时数据库进程崩溃本身也可能触发 bin log 文件的不完整。因为部分 bin log 还停留在缓存中没落盘进程重启后这些内容就没了。不要以为 bin log 参数为 0 只会影响系统崩溃场景。4.2 如何判断一个 bin log 文件是不是完整的排查主从问题或做恢复时最常做的一件事就是检查某个 bin log 文件是否完整。方法不难核心是看事务边界。bin log 文件开头有一个固定的文件头标记。内部每个事务以 BEGIN 事件开始一个事务包含的各类变更事件之后以 XID_EVENT 或 QUERY_EVENT 的 COMMIT 形式收尾。没有结尾的事件就是未完事务。正常关闭或轮转生成的 bin log 末尾还会有一个 ROTATE_EVENT标识下一个 bin log 文件信息。实操时可以先用 mysqlbinlog 把文件解析出来重点看文件尾部的耗时和 XID。如果文件尾部是一个被截断的事务事件大概率是异常断电导致的半截文件。这种文件拿去回放要么会报错要么会在回放时出现主键冲突、数据对不上的情况。如果发现 bin log 不完整又确实需要恢复数据原则是优先用完整的全量备份回到某个可靠时间点再应用不完整文件之前最后一个完整事务位置之后的 bin log。缺失的事务只能人工根据业务情况补齐没有太好的自动化办法。4.3 自己动手模拟一次“半提交”状态理解二阶段提交最好的方式不是看一百篇文章而是自己造一次崩溃现场。最直接的做法是在一个事务里故意加一个耗时的循环比如通过存储过程或应用代码在事务中 sleep然后在另一个线程里执行 SHOW ENGINE INNODB STATUS观察事务的状态。也可以直接查看 performance_schema 里的事务表和日志相关表确认 prepare 状态存在。但要看到崩溃恢复的完整效果还是要维持事务提交与 kill 进程的时机竞争。我试过的一种可复现做法是开一个大事务修改几万行数据同时在应用层设置一个断点卡住提交前的位置。在断点处强行 kill 掉数据库进程模拟在 redo 已刷盘、bin log 未写全的窗口崩溃。重启后去看库里的数据量你会发现事务被回滚了。再把断点移到提交代码之后、应用收到响应之前的位置kill 进程重启后事务是提交状态。这两种结果的差别就是 prepare 和 commit 的差别也是二阶段提交里 bin log 是否完整写入的差别。做这类实验时注意不要在真实生产库上搞建议起一个干净的本地实例配好双 1关闭自动提交用测试表操作。反复几次之后你对崩溃恢复的几个状态会有特别直观的感受。4.4 误删数据后利用 bin log 做时间点恢复的实操流程最后一个场景也是 DBA 工作中最常遇到的手滑删了一批数据或者 UPDATE 忘加 WHERE 条件。这时候不用重装实例只要你之前开了 bin log并且 bin log 文件还在就有机会救回来。整体思路是先找到误操作发生前的 bin log 位置再把后续的 bin log 回放到一个临时实例导出需要的数据最后导入原库。步骤大致如下先确认当前实例的 bin log 开启状态和文件列表。在命令行执行 SHOW BINARY LOGS找出误操作时间段对应的 bin log 文件。用 mysqlbinlog 解析误操作前后两个文件定位到那条要命的 SQL。row 格式下会看到明确的 DELETE 事件或 UPDATE 事件记录它的 position。如果不知道具体时间就用 --start-datetime 和 --stop-datetime 配合逐步缩小范围。准备一台干净的临时实例把全量备份先恢复到误操作之前的时间点然后应用 bin log 直到误操作位置的前一个字节。注意 stop-position 一定不要包含那条错误 SQL。在临时实例里导出你需要的数据。如果是 DELETE 误删就把这段 bin log 用反操作方式处理如果是 UPDATE 误改从临时实例导出正确行的值再导回原库。确认无误后把数据还原回生产环境。回写之前再次确认影响行数、业务影响面尽量选业务低峰期操作。这个流程里最容易踩的坑有三个。第一个是恢复了临时实例但忘记把临时实例的 super_read_only 打开导致后续 bin log 回放顺序受影响。第二个是 mysqlbinlog 导出时没有加 --base64-outputdecode-rowsrow 格式下看到的全是编码内容没法直接分析。第三个是回放时没有从全量备份的 bin log 位置接着放而是从头放了一遍导致主键冲突。这三个坑我都踩过写出来给你避雷。4.5 几个值得长期关注的监控点日志机制讲到最后给几个日常运维能用上的观察指标。redo log 的写入是否频繁落盘可以通过 SHOW ENGINE INNODB STATUS 看到 log 相关信息和操作系统刷盘统计。重点关注日志写等待时间如果 redo 写入经常处于等待状态优先检查磁盘性能尤其是磁盘是不是机械盘、是否有其他任务抢占 IO。bin log 这边要关注文件增长速度和磁盘剩余空间以及每个 bin log 文件的写入是否正常轮转。主从同步出现延迟除了网络因素大概率是 bin log 较大加上从库回放能力不足。可以看从库的复制线程状态确认 IO 线程和 SQL 线程之间是否有积压。undo log 则需要看信息里面的 history list length这个值代表未清理的历史版本链表长度。如果这个值持续增大说明存在长事务或者有非常老的读事务一直不结束导致 undo 无法清理。它大涨通常意味着你的某条业务 SQL 跑太久了或者是连接池里的连接长时间不提交、不关闭事务。最后说点实在的我在多次处理数据库故障之后最大的体会是很多看似玄学的问题追到根上其实都是日志问题。主从延迟卡死去翻 bin log 的写入和回放实例崩溃恢复后发现数据不对回去看 redo 和 bin log 的 XID 是否对得上长事务拖垮整个实例查 undo 的历史版本堆积。把这些日志机制吃透了你再去看那些部署参数、高可用方案、备份恢复策略会发现每个设计都有它对应的底层逻辑。如果只记一句话那就是redo 保证你提交的数据不丢bin log 保证你能把数据同步出去且能恢复回来undo 保证你随时有反悔的余地。而二阶段提交就是让这三件事在同一个事务上同时成立的那道锁。