概述

mysql的日志系统比较庞大，主要为了实现mysql中各种各样的功能。

在mysql中，日志主要分为以下几类：

1. 重做日志（redo log）
2. 回滚日志（undo log)
3. 二进制日志（bin log）
4. 错误日志（error log）
5. 慢查询日志（slow query log）
6. 一般查询日志（general log）
7. 中继日志（relay log）

其中redo log和undo log主要在事务中使用；bin log主要用于主从服务器之间的数据同步，以及服务器遇到故障时数据的无损失恢复；slow query log在我们查询和优化sql时使用。其他的不是很重要。

日志的重要性不言而喻，到那时也会带来一些问题，比如日志功能 降低MySQL数据库的性能 ，占用大量的磁盘空间 。

重点学习bin log、undo log、redo log三大日志，其他了解即可。

错误日志（error log）

错误日志是MySQL中最重要的日志之一，他记录了当mysql启动和停止时，以及服务器在运行过程中发生任何严重错误的相关信息。当数据库出现任何故障导致无法正常使用时，建议首先查看此日志。

该日志默认是开启的，默认存放目录（Linux）/var/log/，默认的日志文件名为mysql.log，

查看日志位置:

show variables like '%log_error%';

指定日志路径两种方法:

• 编辑my.cnf 写入 log-error=[path]
• 通过命令参数错误日志 mysqld_safe –user=mysql –log-error=[path] &

慢查询日志（slow query log）

慢查询日志记录了所有执行时间超过参数long_query_time设置值并且扫描记录数不小于min_examined_row_limit 的所有的SQL语句的日志，默认未开启。long_query_time默认为10秒，最小为0，精度可以到微秒。

如果需要开启慢查询日志，需要在MySQL的配置文件/etc/my.cnf中配置如下参数

#慢查询日志
slow_query_log=1
#执行时间参数
long_query_time=2

默认情况下，不会记录管理语句，也不会记录不使用索引进行查找的查询。可以使用log_slow_admin_statements和log_queries_not_using_indexs更改此行为，如下:

#记录执行较慢的管理语句
log_slow_admin_statements =1
#记录执行较慢的未使用索引的语句
log_queries_not_using_indexes = 1

一般查询日志( general log )

记录了服务器接收到的每一个查询或是命令，无论这些查询或是命令是否正确甚至是否包含语法错误，general log 都会将其记录下来 ，记录的格式为 {Time ，Id ，Command，Argument }。也正因为mysql服务器需要不断地记录日志，开启General log会产生不小的系统开销。 因此，Mysql默认是把General log关闭的。

查看日志位置：

show variables like '%general%';

通过修改MySQL的配置文件/etc/my.cnf

#该选项用来开启查询日志 ， 可选值 ：0 或者 1 ；0 代表关闭， 1 代表开启
general_log=1
#设置日志的文件名 ， 如果没有指定， 默认的文件名为 host_name.log
general_log_file=mysql_query.log

中继日志（relay log）

中继日志只在集群主从或主主服务器架构的从服务器上存在。

MySQL 进行主主复制或主从复制的时候会在要复制的服务器下面产生相应的 relay log。

relay log 是怎么产生的呢？

从服务器 I/O 线程将主服务器的 Binlog 日志读取过来，解析到各类 Events 之后记录到从服务器本地文件，这个文件就被称为 relay log。然后 SQL 线程会读取 relay log 日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。中继日志充当缓冲区，这样 master 就不必等待 slave 执行完成才发送下一个事件。

Buffer Pool 缓存

在讲bin log、undo log、redo log三大日志前，先来了解下Buffer Pool 缓存是什么。

Innodb 存储引擎设计了一个缓冲池（Buffer Pool），来提高数据库的读写性能。

有了 Buffer Pool 后：

• 当读取数据时，如果数据存在于 Buffer Pool 中，客户端就会直接读取 Buffer Pool 中的数据，否则再去磁盘中读取。
• 当修改数据时，如果数据存在于 Buffer Pool 中，那直接修改 Buffer Pool 中数据所在的页，然后将其页设置为脏页（该页的内存数据和磁盘上的数据已经不一致），为了减少磁盘I/O，不会立即将脏页写入磁盘，后续由后台线程选择一个合适的时机将脏页写入到磁盘。

InnoDB 引擎在适当的时候，由后台线程将缓存在 Buffer Pool 的脏页刷新到磁盘里的技术也称为 WAL （Write-Ahead Logging）技术。

InnoDB 会把存储的数据划分为若干个「页」，以页作为磁盘和内存交互的基本单位，一个页的默认大小为 16KB。因此，Buffer Pool 同样需要按「页」来划分。

在 MySQL 启动的时候，InnoDB 会为 Buffer Pool 申请一片连续的内存空间，然后按照默认的16KB的大小划分出一个个的页， Buffer Pool 中的页就叫做缓存页。此时这些缓存页都是空闲的，之后随着程序的运行，才会有磁盘上的页被缓存到 Buffer Pool 中。

所以，MySQL 刚启动的时候，你会观察到使用的虚拟内存空间很大，而使用到的物理内存空间却很小，这是因为只有这些虚拟内存被访问后，操作系统才会触发缺页中断，申请物理内存，接着将虚拟地址和物理地址建立映射关系。

Buffer Pool 除了缓存「索引页」和「数据页」，还包括了 Undo 页，插入缓存、自适应哈希索引、锁信息等等。

回滚日志（undo log)

概述

undo log 是一种用于撤销回退的日志。在事务没提交之前，MySQL 会先记录更新前的数据到 undo log 日志文件里面，当事务回滚时，可以利用 undo log 来进行回滚。

每当 InnoDB 引擎对一条记录进行操作（修改、删除、新增）时，要把回滚时需要的信息都记录到 undo log 里，比如：

• 在插入一条记录时，要把这条记录的主键值记下来，这样之后回滚时只需要把这个主键值对应的记录删掉就好了；
• 在删除一条记录时，要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了；
• 在更新一条记录时，要把被更新的列的旧值记下来，这样之后回滚时再把这些列更新为旧值就好了。

在发生回滚时，就读取 undo log 里的数据，然后做原先相反操作。

undo log 作用

• 事务回滚：数据回滚操作（事务的原子性实现），在事务执行过程中，如果出现错误或需要回滚操作，Undo log 可以恢复事务执行之前的数据状态，实现事务的回滚操作。
• 并发控制：实现 MVCC 多版本并发控制，通过 Undo log 可以实现数据库并发事务的隔离性和一致性，避免数据读取和写入的冲突。

undo log 的存储机制

undo Log 存储采用分段（segment）的方式管理和记录。

undo log 的存储控制可以通过下面这条参数实现：

show variables like '%innodb_undo%';

在 InnoDB 存储数据的文件中，包含了一种回滚段（Rollback Segment），每个回滚段中有 1024 个Undo log segment（版本 5.5 后，可以支持 128 个 Rollback Segment）。

每个回滚段都对应一个或多个 Undo log 日志文件，用于记录事务执行前的数据快照、以及存储事务操作的详细信息，例如插入、更新或删除。

一条记录的每一次更新操作产生的 undo log 格式都有一个 roll_pointer 指针和一个 trx_id 事务id：

• 通过 trx_id 可以知道该记录是被哪个事务修改的；
• 通过 roll_pointer 指针可以将这些 undo log 串成一个链表，这个链表就被称为版本链；

版本链如下图：

Undo log 的分类

在InnoDB存储引擎中，undo log分为：insert undo log 和 update undo log

insert undo log是指在insert 操作中产生的undo log，因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作。

而update undo log记录的是对delete 和update操作产生的undo log，该undo log可能需要提供MVCC机制，因此不能再事务提交时就进行删除。提交时放入undo log链表，等待后台 purge 线程进行回收处理的进行最后的删除。

重做日志（redo log）

redo log 是物理日志，记录了某个数据页做了什么修改，当数据库进行数据修改操作（如插入、更新、删除）时，会对数据本身进行修改，并生成一个对应的重做日志记录。

这个重做日志记录包含了修改的细节。例如，被修改的数据块位置、修改前后的值等。这些日志记录被持久化保存在磁盘上，确保即使系统崩溃，也能通过重做日志来恢复数据的一致性。

Redo log 的作用

1. 保证事务的持久性

在事务提交时，只要先将 redo log 持久化到磁盘即可，可以不需要等到将缓存在 Buffer Pool 里的脏页数据持久化到磁盘。当系统崩溃时，虽然脏页数据没有持久化，但是 redo log 已经持久化，接着 MySQL 重启后，可以根据 redo log 的内容，将所有数据恢复到最新的状态。这个能力称为 crash-safe（崩溃恢复）。从而保证了事务的持久性。

过程如下：

2. 提高事务的提交效率

写入 redo log 的方式使用了追加操作， 所以磁盘操作是顺序写，而写入数据需要先找到写入位置，然后才写到磁盘，所以磁盘操作是随机写。磁盘的「顺序写 」比「随机写」 高效的多，因此 redo log 写入磁盘的开销更小。

Redo log 的结构

Redo log 的存储都是以 块（block） 为单位进行存储的。

每个块由三部分组成：日志块头（log block header）、日志块尾（log block tailer）、日志本身。

每个块是 512 字节，同磁盘扇区大小一致，可以保证块的写入是原子操作。

一个日志文件由多个块所构成，多个日志文件形成一个重做日志文件组（Redo log group）。

redo log 的刷盘

redo log 不是直接写入磁盘的，因为这样会产生大量的 I/O 操作，而且磁盘的运行速度远慢于内存。

所以，redo log 也有自己的缓存—— redo log buffer，每当产生一条 redo log 时，会先写入到 redo log buffer，后续在持久化到磁盘如下图：

redo log buffer 默认大小 16 MB，可以通过 innodb_log_Buffer_size 参数动态的调整大小，增大它的大小可以让 MySQL 处理「大事务」是不必写入磁盘，进而提升写 IO 性能。

redo log 刷盘策略

刷盘策略由参数 innodb_flush_log_at_trx_commit 参数控制，可取的值有：0、1、2，默认值为 1，这三个值分别代表的策略如下：

• 当设置该参数为 0 时，表示每次事务提交时 ，还是将 redo log 留在 redo log buffer 中 ，该模式下在事务提交时不会主动触发写入磁盘的操作。
• 当设置该参数为 1 时，表示每次事务提交时，都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘，这样可以保证 MySQL 异常重启之后数据不会丢失。
• 当设置该参数为 2 时，表示每次事务提交时，都只是缓存在 redo log buffer 里的 redo log 写到 redo log 文件，注意写入到「 redo log 文件」并不意味着写入到了磁盘，因为操作系统的文件系统中有个 Page Cache，Page Cache 是专门用来缓存文件数据的，所以写入「 redo log文件」意味着写入到了操作系统的文件缓存。

这三个参数的数据安全性和写入性能的比较如下：

• 数据安全性：参数 1 > 参数 2 > 参数 0
• 写入性能：参数 0 > 参数 2> 参数 1

InnoDB 的后台线程每隔 1 秒：

• 针对参数 0 ：会把缓存在 redo log buffer 中的 redo log ，通过调用 write() 写到操作系统的 Page Cache，然后调用 fsync() 持久化到磁盘。所以参数为 0 的策略，MySQL 进程的崩溃会导致上一秒钟所有事务数据的丢失;
• 针对参数 2 ：调用 fsync，将缓存在操作系统中 Page Cache 里的 redo log 持久化到磁盘。所以参数为 2 的策略，较取值为 0 情况下更安全，因为 MySQL 进程的崩溃并不会丢失数据，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。

如何选择刷盘策略：

• 在一些对数据安全性要求比较高的场景中，显然 innodb_flush_log_at_trx_commit 参数需要设置为 1。
• 在一些可以容忍数据库崩溃时丢失 1s 数据的场景中，我们可以将该值设置为 0，这样可以明显地减少日志同步到磁盘的 I/O 操作。
• 安全性和性能折中的方案就是参数 2，虽然参数 2 没有参数 0 的性能高，但是数据安全性方面比参数 0 强，因为参数 2 只要操作系统不宕机，即使数据库崩溃了，也不会丢失数据，同时性能方便比参数 1 高。

redo log 文件写入

默认情况下， InnoDB 存储引擎有 1 个重做日志文件组( redo log Group），「重做日志文件组」由有 2 个 redo log 文件组成，这两个 redo 日志的文件名叫 ：ib_logfile0 和 ib_logfile1 。

在重做日志组中，每个 redo log File 的大小是固定且一致的，假设每个 redo log File 设置的上限是 1 GB，那么总共就可以记录 2GB 的操作。

重做日志文件组是以循环写的方式工作的，从头开始写，写到末尾就又回到开头，相当于一个环形。

所以 InnoDB 存储引擎会先写 ib_logfile0 文件，当 ib_logfile0 文件被写满的时候，会切换至 ib_logfile1 文件，当 ib_logfile1 文件也被写满时，会切换回 ib_logfile0 文件。

我们知道 redo log 是为了防止 Buffer Pool 中的脏页丢失而设计的，那么如果随着系统运行，Buffer Pool 的脏页刷新到了磁盘中，那么 redo log 对应的记录也就没用了，这时候我们擦除这些旧记录，以腾出空间记录新的更新操作。

redo log 是循环写的方式，相当于一个环形，InnoDB 用 write pos 表示 redo log 当前记录写到的位置，用 checkpoint 表示当前要擦除的位置，如下图：

图中的：

• write pos 和 checkpoint 的移动都是顺时针方向；
• write pos ～ checkpoint 之间的部分（图中的红色部分），用来记录新的更新操作；
• check point ～ write pos 之间的部分（图中蓝色部分）：待落盘的脏数据页记录；

如果 write pos 追上了 checkpoint，就意味着 redo log 文件满了，这时 MySQL 不能再执行新的更新操作，也就是说 MySQL 会被阻塞（因此所以针对并发量大的系统，适当设置 redo log 的文件大小非常重要），此时会停下来将 Buffer Pool 中的脏页刷新到磁盘中，然后标记 redo log 哪些记录可以被擦除，接着对旧的 redo log 记录进行擦除，等擦除完旧记录腾出了空间，checkpoint 就会往后移动（图中顺时针），然后 MySQL 恢复正常运行，继续执行新的更新操作。

所以，一次 checkpoint 的过程就是脏页刷新到磁盘中变成干净页，然后标记 redo log 哪些记录可以被覆盖的过程。

二进制日志（bin log）

概述

bin log 是 MySQL 服务层实现的日志，记录所有数据库表结构变更以及数据修改的二进制日志(不会记录查询和show这类操作)。

因为binlog占用系统资源较大 1%，所以一般是关闭状态。

当需要主从复制:获数据备份时我们才开启。可使用如下参数开启：

log-bin=/var/lib/mysql/mysql-bin

通过命令行的方式开启 Bin log：

SET SQL_LOG_BIN=1

bin log 的作用

1. 主从复制

主数据库将修改操作记录到 bin log 中，然后主库传输到从库上，从数据库通过解析 bin log 实现数据的同步。传输的这个过程一般是异步的，也就是主库上执行事务操作的线程不会等待复制 binlog 的线程同步完成。

还需要配合中继日志完成。

具体详细过程如下：

• MySQL 主库在收到客户端提交事务的请求之后，会先写入 binlog，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端“操作成功”的响应。
• 从库会创建一个专门的 I/O 线程，连接主库的 log dump 线程，来接收主库的 binlog 日志，再把 binlog 信息写入 relay log 的中继日志里，再返回给主库“复制成功”的响应。
• 从库会创建一个用于回放 binlog 的线程，去读 relay log 中继日志，然后回放 binlog 更新存储引擎中的数据，最终实现主从的数据一致性。

2. 数据恢复

bin log 记录了每个事务的详细操作，包括数据的修改和事务的状态变更。

使用 Bin log 恢复 MySQL 数据，简单地说，就是让 MySQL 将保存在 Bin log 日志中指定段落区间的 sql 语句，逐个重新执行一次而已。

bin log 日志结构

bin log 日志文件包含了索引文件和具体日志文件。

• **索引文件：**用于跟踪日志文件，每行一个日志文件。默认情况下，索引文件名为{Host名}-bin.index。
• **日志文件：**是由一系列事件(Binary Log Events)组成。默认情况下，文件名为{Host名}-bin.NNNNNN。后缀六个数字，是编号，用于区分不同的日志文件。

每个 Bin log 事件由四个部分组成：

• 通用 Header：存放事件的基本信息：事件类型和事件数据大小。
• Post Header：存放特定事件类型的相关信息
• 事件实体：存储事件的数据，如执行过的语句和变更的实际数据
• Checksum：MySQL5.6 新特性，用于检查数据是否损坏。

Bin log 的相关参数

• log_bin ：启用 Bin log 功能，并指定路径名称
• log_bin_index ：指定二进制索引文件的路径与名称
• Bin log_do_db ：只记录指定数据库的二进制日志
• Bin log_ignore_db ：不记录指定的数据库的二进制日志
• max_Bin log_cache_size ：Bin log 使用的内存最大的尺寸
• Bin log_cache_size ：Bin log 使用的内存大小
• Bin log_cache_use ：使用二进制日志缓存的事务数量
• Bin log_cache_disk_use : 使用二进制日志缓存
• max_Bin log_size ：Bin log 最大值，最大和默认值是1GB
• sync_Bin log ：这个参数直接影响MySQL的性能和完整性
• sync_Bin log=0 ：当事务提交后，MySQL 仅仅是将 Bin log_cache 中的数据写入 Bin log 文件，但不执行 fsync 之类的磁盘 同步指令通知文件系统将缓存刷新到磁盘，而让Filesystem自行决定什么时候来做同步，这个是性能最好的。
• sync_Bin log=n ：在进行n次事务提交以后，MySQL 将执行一次fsync之类的磁盘同步指令，同志文件系统将 Bin log 文件缓存刷新到磁盘。

在 MySQL 中，默认设置是 sync_Bin log=0 ，即不作任何强制性的磁盘刷新指令。

sync_Bin log=0 的性能最好、但风险也最大，一旦系统绷 Crash ，在文件系统缓存中的所有 Bin log 信息都会丢失。

bin log 的三种模式

1. Statement 模式

基于语句的复制模式。

Statement 模式将数据库中执行的修改操作记录为 SQL 语句，再从数据库上执行相同的 SQL 语句来实现数据同步。

优点：简单明了，易于理解和实现。

缺点：在执行涉及非确定性函数、触发器和存储过程等操作时，可能会导致不一致的结果。

适用于大多数情况下的数据库复制需求。

2. Row模式

Row 模式是基于行的复制模式，它将数据库中实际修改的行记录写入 Binlog ，从数据库通过解析 Binlog

来逐行执行相应的修改操作。相对 statement ，Row 模式更加精确、安全，能够确保数据的一致性。

优点：能准确复制修改的行记录，避免了语句复制模式下的不确定性问题。

缺点：如果 Binlog 文件较大，传输成本就会很高，在某些情况下，可能会导致性能下降。

3. Mixed 模式

Mixed 模式（混合模式）是将语句复制模式和行复制模式结合起来使用。

大多数的修改操作，通常使用 Statement 模式记录对应的 SQL 语句。

一些特殊的操作，涉及非确定性函数和存储过程等，则使用 Row 模式记录修改的行记录。

Mixed 模式综合了语句复制模式和行复制模式的优点，能够在大多数情况下高效地记录修改操作，并在需要时使用行复制模式确保数据的准确性。但 Mixed 模式对一些特殊操作的处理可能会很复杂，需要特别注意下配置和管理。

bin log 的刷盘

事务执行过程中，先把日志写到 binlog cache（Server 层的 cache），事务提交的时候，再把 binlog cache 写到 binlog 文件中。

一个事务的 binlog 是不能被拆开的，因此无论这个事务有多大（比如有很多条语句），也要保证一次性写入。这是因为有一个线程只能同时有一个事务在执行的设定，所以每当执行一个 begin/start transaction 的时候，就会默认提交上一个事务，这样如果一个事务的 binlog 被拆开的时候，在备库执行就会被当做多个事务分段自行，这样破坏了原子性，是有问题的。

MySQL 给每个线程分配了一片内存用于缓冲 binlog ，该内存叫 binlog cache，参数 binlog_cache_size 用于控制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。

在事务提交的时候，执行器把 binlog cache 里的完整事务写入到 binlog 文件中，并清空 binlog cache。如下图：

虽然每个线程有自己 binlog cache，但是最终都写到同一个 binlog 文件：

• 图中的 write，指的就是指把日志写入到 binlog 文件，但是并没有把数据持久化到磁盘，因为数据还缓存在文件系统的 page cache 里，write 的写入速度还是比较快的，因为不涉及磁盘 I/O。
• 图中的 fsync，才是将数据持久化到磁盘的操作，这里就会涉及磁盘 I/O，所以频繁的 fsync 会导致磁盘的 I/O 升高。

MySQL提供一个 sync_binlog 参数来控制数据库的 binlog 刷到磁盘上的频率：

• sync_binlog = 0 的时候，表示每次提交事务都只 write，不 fsync，后续交由操作系统决定何时将数据持久化到磁盘；
• sync_binlog = 1 的时候，表示每次提交事务都会 write，然后马上执行 fsync；
• sync_binlog =N(N>1) 的时候，表示每次提交事务都 write，但累积 N 个事务后才 fsync。

在MySQL中系统默认的设置是 sync_binlog = 0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦主机发生异常重启，还没持久化到磁盘的数据就会丢失。

而当 sync_binlog 设置为 1 的时候，是最安全但是性能损耗最大的设置。因为当设置为 1 的时候，即使主机发生异常重启，最多丢失一个事务的 binlog，而已经持久化到磁盘的数据就不会有影响，不过就是对写入性能影响太大。

如果能容少量事务的 binlog 日志丢失的风险，为了提高写入的性能，一般会 sync_binlog 设置为 100~1000 中的某个数值。

bin log、undo log、redo log总结

1. 数据记录方式

• Bin log：以二进制格式记录数据库的修改操作。
• Redo log：以固定大小的物理日志文件记录数据库页的物理修改。
• Undo log：以逻辑方式记录事务执行过程中旧值的备份。

2. 大小

• Binlog大小：Binlog的大小取决于数据库的操作类型和频率。它记录了数据库的逻辑变更操作，因此其大小与执行的SQL语句数量和数据修改量相关。
• Redo Log大小：Redo Log的大小取决于事务的数量和大小，以及数据库的写入操作频率。它记录了数据库的物理变更操作，因此其大小与事务的提交频率和数据修改量相关。
• Undo Log大小：Undo Log的大小取决于数据库中活跃的事务数量和每个事务的大小。它记录了事务的回滚信息，因此其大小与事务的数量和修改的数据量相关。

3. 存储方式

• Binlog存储方式：Binlog通常以二进制文件的形式存储在文件系统中，可以配置存储位置和保留时间。它可以在数据库服务器上本地存储，也可以通过网络传输到其他服务器进行复制和数据同步。
• Redo Log存储方式：Redo Log通常以循环写入的方式存储在专用的磁盘空间中，称为Redo Log文件组。数据库引擎会将Redo Log追加写入到Redo Log文件中，以确保持久性和崩溃恢复。
• Undo Log存储方式：Undo Log通常以数据页或回滚段的形式存储在数据库的数据文件中。数据库引擎会为每个事务分配Undo Log空间，用于记录事务的回滚信息，并在需要回滚或读取旧版本数据时使用。

4. 触发时机

• Binlog：在事务提交时，Binlog将记录该事务的逻辑变更操作。事务提交可以显式地通过COMMIT语句触发，或者在自动提交模式下，每个独立的SQL语句执行后都将触发事务的提交。
• Redo Log：在事务执行期间，Redo Log会记录该事务对数据库进行的物理变更操作。这些变更操作将被写入Redo Log缓冲区。在事务提交之前或事务发生崩溃时，Redo Log缓冲区中的日志将被刷新到磁盘上的Redo Log文件中。
• Undo Log：在事务执行期间，Undo Log记录了事务对数据库进行的修改操作的撤销信息，用于实现事务的回滚和并发控制（如多版本并发控制）。在事务执行过程中，对数据进行修改时，相应的Undo Log记录将被写入Undo Log缓冲区或直接写入Undo Log文件中。

5. 应用场景

• Bin log：用于数据恢复、主从复制、数据审计和数据备份等。
• Redo log：用于保证事务的持久性和故障恢复。
• Undo log：用于事务的回滚和并发控制。

参考：
内容和图片摘取以下博文
https://mp.weixin.qq.com/s/AhW2VBWuuU4WqtBvvVGUuA
https://xiaolincoding.com/mysql/log/how_update.html
https://mp.weixin.qq.com/s/6Maca3ZX62cRY5-0uNuR4w
https://mp.weixin.qq.com/s/4QHFchIvNh-R4ruuwZahKg
https://mp.weixin.qq.com/s/VXyMS4UHKOHbW2qfffIoQA