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

最新推荐文章于 2024-05-29 17:07:22 发布

Java_LingFeng

最新推荐文章于 2024-05-29 17:07:22 发布

阅读量1k

点赞数

文章标签：数据库 mysql sql 程序人生后端

本文链接：https://blog.csdn.net/Java_LingFeng/article/details/128264658

版权

本文详细介绍了MySQL中的核心日志——binlog、redo log和undo log。binlog记录所有写操作，用于主从复制和数据恢复，有三种格式：STATEMENT、ROW和MIXED。redo log是InnoDB引擎的重做日志，用于保证数据的持久性，其写入策略通过innodb_flush_log_at_trx_commit参数控制。undo log则用于事务回滚和MVCC，保证事务的原子性。理解这些日志对于数据库管理和优化至关重要。

摘要由CSDN通过智能技术生成

hello，大家好。

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

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

1 binlog

1.1 binlog 设计目标

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

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

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

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

主从复制：在 Master 端开启 binlog ，然后将 binlog 发送到各个 Slave 端， Slave 端重放 binlog 来达到主从数据一致。
数据恢复：通过使用 mysqlbinlog 工具来恢复数据。

1.2 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。