硬核干货，带你一文掌握 MySQL 的binlog 、redo log、undo log

关注

VIP免费原创最新推荐文章于 2026-04-21 20:23:14 发布 1.1k 阅读 AI 写同款· GEO 优化 ›

hello，大家好。

在MySQL 中我们经常会接触到三个核心日志，它们分别是：binlog 、redo log、undo log。

好多同学对于它们可能并不陌生，但是具体区分起来各自的功能用途以及实现原理，那可能认知就会比较模糊了，今天就跟大家一起，来清晰明了的介绍一下这些日志的核心思想和功能原理。

binlog 记录了对MySQL数据库执行更改的所有的写操作，包括所有对数据库的数据、表结构、索引等等变更的操作。

注意：这其中不包含SELECT、SHOW等，因为对数据没有修改

只要是对数据库有变更的操作都会记录到binlog里面来，我们可以把数据库的数据看做银行账户里的余额，而binlog就相当于我们银行卡的流水记录。账户余额只是一个结果，至于这个结果怎么来的，那就必须得看流水了。

在实际应用中， binlog 的主要应用场景分别是主从复制和数据恢复。

binlog 日志有三种格式，分别为 STATMENT 、 ROW 和 MIXED。

在 MySQL 5.7.7 之前，默认的格式是 STATEMENT ， MySQL 5.7.7 之后，默认值是 ROW。日志格式通过 binlog-format 指定。

ROW：基于行的复制（row-based replication, RBR），不记录每条SQL语句的上下文信息，仅需记录哪条数据被修改了。如果一个update语句修改一百行数据，那么这种模式下就会记录100行对应的记录日志。
优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题；
缺点：会产生大量的日志，尤其是 alter table 的时候会让日志暴涨。
STATMENT：基于SQL语句的复制( statement-based replication, SBR )，每一条会修改数据的SQL语句会记录到 binlog 中。相对于ROW模式，STATEMENT模式下只会记录这个 update 的语句，所以此模式下会非常节省日志空间，也避免着大量的IO操作。
优点：不需要记录每一行的变化，减少了 binlog 日志量，节约了 IO , 从而提高了性能；
缺点：在某些情况下会导致主从数据不一致，比如执行sysdate() 、 slepp() 等。
MIXED：基于 STATMENT 和 ROW 两种模式的混合复制（mixed-based replication, MBR），一般的复制使用 STATEMENT 模式保存 binlog ，对于一些函数，STATEMENT 模式无法复制的操作使用 ROW 模式保存 binlog。