导语

MySQL是一种广泛使用的开源关系型数据库管理系统，由瑞典公司MySQL AB开发，现由Oracle公司维护。它以其高性能、可靠性和易用性而著称，广泛应用于各种Web应用程序。MySQL支持多种操作系统，包括Windows、Linux和macOS，且兼容多种编程语言，如PHP、Java和Python。其主要特点包括支持多用户访问、强大的数据安全性和灵活的存储引擎选择。MySQL采用了结构化查询语言（SQL）进行数据库操作，具有丰富的功能，如事务处理、外键支持和全文索引，是构建动态网站和应用程序的理想选择。

MySQL 日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 binlog（归档日志）和事务日志 redo log（重做日志）和 undo log（回滚日志）。

redo log

顾名思义，Redo Log（重做日志）指的是在数据库出现意外情况时，能够重新执行某种操作以恢复数据。在 MySQL 中，事务中修改的任何数据，都会将最新的数据写入 Redo Log 中进行备份。

随着事务操作的执行，Redo Log 日志会不断产生。在事务提交时，Redo Log 会被写入 Redo Buffer。但 Redo Buffer 并不会随着事务提交立即写入磁盘，而是等到事务操作的脏页写入磁盘之后，Redo Log 的使命才算完成。此时，Redo Log 日志占用的空间可以被后续产生的日志覆盖和重新利用。

Redo Log 是 InnoDB 存储引擎独有的，它赋予了 MySQL 崩溃恢复的能力，保证了事务的持久性。

redo log的作用

Redo Log 用来记录数据页的更改，以便在数据库崩溃或异常关闭时，通过重做 Redo Log 中的操作来恢复未完成的事务并保证数据的一致性。

例如，当 MySQL 实例挂掉或宕机时，重启后，InnoDB 存储引擎会使用 Redo Log 恢复数据，确保数据的持久性与完整性。

• Redo 日志文件是 InnoDB 特有的，它是存储引擎级别的，不是 MySQL 级别的。
• 服务器宕机，MySQL 重启时，利用 Redo Log 日志内容恢复缓冲区数据。
• 一般情况下，Redo Log Buffer 数据写入磁盘的策略是立即刷入磁盘。

Buffer Pool是什么？

MySQL 的数据存储在磁盘中。当需要更新一条记录时，InnoDB 引擎会先在内存中进行更新（同时将该页标记为脏页），然后将本次对这个页的修改以 redo log 的形式记录下来，此时更新操作就算完成了。

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

WAL 技术指的是，MySQL 的写操作并不是立刻写到磁盘上，而是先写日志，然后在合适的时间再写到磁盘上。

Buffer Pool 的作用

1. 读取数据：当读取数据时，如果数据存在于 Buffer Pool 中，客户端就会直接读取 Buffer Pool 中的数据，否则再去磁盘中读取。这减少了磁盘 I/O 操作，提高了读取性能。
2. 修改数据：当修改数据时，如果数据存在于 Buffer Pool 中，就直接修改 Buffer Pool 中数据所在的页，然后将其页设置为脏页（该页的内存数据和磁盘上的数据已经不一致）。为了减少磁盘 I/O，不会立即将脏页写入磁盘，而是由后台线程在合适的时机将脏页写入磁盘。

工作机制

• 数据读取：首先从 Buffer Pool 中查找数据，如果命中则直接返回。如果未命中，则从磁盘加载数据页到 Buffer Pool 中，再返回数据。
• 数据修改：修改操作首先在 Buffer Pool 中进行，同时将修改记录到 redo log。修改的数据页被标记为脏页。后台线程会在适当的时候将这些脏页刷新到磁盘。

这种机制有效地减少了磁盘 I/O 操作，提高了数据库的整体性能。

redo log的写入方式

在 MySQL 中，数据是以页为单位存储的。当你查询一条记录时，会从硬盘中加载一页数据，这些数据被称为数据页，并放入到 Buffer Pool 中。

后续的查询操作首先会在 Buffer Pool 中查找数据，如果没有命中再去硬盘加载，从而减少硬盘 IO 开销，提升性能。

更新表数据时也是如此。如果 Buffer Pool 中存在要更新的数据，就直接在 Buffer Pool 中进行更新。同时，将“在某个数据页上做了什么修改”记录到 Redo Log Buffer 中，然后刷盘到 Redo Log 文件中。

理想情况下，事务一提交就会进行刷盘操作，但实际上，刷盘的时机是根据具体策略来决定的。

小贴士：每条 Redo 记录由“表空间号 + 数据页号 + 偏移量 + 修改数据长度 + 具体修改的数据”组成。

redo log 包括两部分内容：

• 日志缓冲（redo log buffer）：位于内存中。
• 日志文件（redo log file）：位于磁盘上。

每当 MySQL 执行一条 DML 语句时，首先会把记录写入 redo log buffer，然后在某个时间点将多个操作记录一次性写入 redo log file。这种先写日志，再写磁盘的技术，就是 WAL（Write-Ahead Logging） 。

在计算机操作系统中，用户空间（user space）下的缓冲区数据，一般是无法直接写入磁盘的，必须经过操作系统内核空间缓冲区（即 OS Buffer）。

1. 日志最开始会写入位于存储引擎 InnoDB 的 redo log buffer，这个是在用户空间完成的。
2. 然后再将日志保存到操作系统内核空间的缓冲区（OS buffer）中。
3. 最后，通过系统调用 fsync()，从 OS buffer 写入到磁盘上的 redo log file 中，完成写入操作。这个写入磁盘的操作，就叫做 刷盘。

redo log日志文件组

在 MySQL 中，redo log 日志文件并不是单独存在的，而是以日志文件组的形式出现。每个 redo 日志文件的大小都是相同的。

InnoDB 存储引擎有 1 个重做日志文件组( redo log Group）

重做日志组采用 循环写 的方式工作。

• Write Pos 是当前记录的位置，一边写一边后移，写到最后一个文件末尾后就回到 0 号文件开头；
• CheckPoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数 据文件；

Write Pos 和 CheckPoint之间还空着的部分，可以用来记录新的操作。如果 Write Pos 追上 CheckPoint，表示已经写满，此时就需要向后移动CheckPoint来擦除数据。

每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文件，默认为ib_logfile0和ib_logfile1 。

可以在MySQL中通过如下命令来查看控制Redo Log的参数。

show variables like '%innodb_log%';

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

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

例如，可以配置一个包含 4 个文件的日志文件组，每个文件的大小为 1GB，这样整个 redo log 日志文件组可以记录 4GB 的内容。

日志文件组采用环形数组的形式进行存储，从头开始写，写到末尾后又回到头部继续写，如下图所示：

如果 write pos 追上了 checkpoint，这表示日志文件组已经满了，此时不能再写入新的 redo log 记录。MySQL 必须停下来，清空一些记录，并将 checkpoint 推进，以便腾出空间。

在 MySQL 8.0.30 之前，可以通过 innodb_log_files_in_group 和 innodb_log_file_size 配置日志文件组的文件数量和文件大小。然而，在 MySQL 8.0.30 及之后的版本中，这两个变量已被废弃，即使指定了它们，也只是用来计算 innodb_redo_log_capacity 的值。而日志文件组的文件数量固定为 32，文件大小为 innodb_redo_log_capacity / 32。

在使用 MySQL 8.0.30 及之后的版本时，推荐使用 innodb_redo_log_capacity 变量来配置日志文件组。

Redo Log 的刷盘时机

InnoDB 在多种情况下会刷新重做日志（Redo Log），以保证数据的持久性和一致性。以下是 InnoDB 刷新重做日志的主要时机：

1. 事务提交
   当事务提交时，log buffer 中的 redo log 会被刷新到磁盘。这可以通过参数 innodb_flush_log_at_trx_commit 来控制，具体细节将在后文提到。

2. log buffer 空间不足
   当 log buffer 中缓存的 redo log 占满了 log buffer 总容量的大约一半时，需要将这些日志刷新到磁盘。

3. 事务日志缓冲区满
   InnoDB 使用一个事务日志缓冲区（transaction log buffer）来暂时存储事务的重做日志条目。当缓冲区满时，会触发日志刷新，将日志写入磁盘。

4. Checkpoint（检查点）
   InnoDB 定期执行检查点操作，将内存中的脏数据（已修改但尚未写入磁盘的数据）刷新到磁盘，并将相应的重做日志一同刷新，以确保数据的一致性。

5. 后台刷新线程
   InnoDB 启动了一个后台线程，负责周期性（每隔 1 秒）地将脏页（已修改但尚未写入磁盘的数据页）刷新到磁盘，并将相关的重做日志一同刷新。

6. 正常关闭服务器
   当 MySQL 服务器正常关闭时，redo log 会被刷新到磁盘，以确保所有未持久化的数据都被写入磁盘。

7. 后台线程主动刷盘
   当 redo log buffer 占用的空间接近 innodb_log_buffer_size 一半时，后台线程也会主动刷盘。

通过这些机制，InnoDB 确保了重做日志的及时刷新，从而保证了数据的持久性和一致性。

刷盘策略

在 MySQL 中，设置正确的刷盘策略 innodb_flush_log_at_trx_commit 是至关重要的。根据不同的刷盘策略配置，MySQL 宕机后可能会存在轻微的数据丢失问题。

innodb_flush_log_at_trx_commit 参数有三种取值，对应三种刷盘策略：

• 0 - 延迟写：事务提交时不会将 redo log buffer 中的日志写入到 OS buffer，而是每秒写入 OS buffer 并调用写入到 redo log file 中。
• 1 - 实时写：事务每次提交都会将 redo log buffer 中的日志写入 OS buffer 并保存到 redo log file 中。
• 2 - 实时写，延迟刷：每次事务提交写入到 OS buffer，然后每秒将日志写入到 redo log file。

0：不进行刷盘
事务提交时不会将 redo log buffer 中的日志写入到 OS buffer，而是每秒写入 OS buffer 并调用写入到 redo log file 中。这种方式性能最高，但最不安全，因为如果 MySQL 挂了或宕机了，可能会丢失最近 1 秒内的事务。

1：每次都进行刷盘
事务每次提交都会将 redo log buffer 中的日志写入 OS buffer 并保存到 redo log file 中。这种方式性能最低，但最安全，因为只要事务提交成功，redo log 记录就一定在磁盘里，不会有任何数据丢失。默认值为 1。为了保证事务的持久性，建议将其设置为 1。另外，InnoDB 存储引擎有一个后台线程，每隔 1 秒会将 redo log buffer 中的内容写到文件系统缓存（page cache），然后调用 fsync 刷盘。即使事务未提交，这些 redo log 记录也可能会被刷盘。

2：放入缓存，系统决定刷盘时机
每次事务提交时只将 log buffer 中的 redo log 内容写入 page cache（文件系统缓存）。这种方式的性能和安全性介于前两者之间。只要事务提交成功，redo log buffer 中的内容会写入文件系统缓存。如果仅仅是 MySQL 挂了，不会有任何数据丢失，但如果宕机，可能会有 1 秒的数据丢失。一般建议选择取值 2，因为 MySQL 挂了数据没有损失，整个服务器挂了才会损失 1 秒的事务提交数据。

• 0：不进行刷盘
  性能最高，但最不安全，可能会丢失最近 1 秒内的事务。
• 1：每次都进行刷盘
  性能最低，但最安全，事务提交成功后 redo log 记录一定在磁盘里，不会有任何数据丢失。
• 2：放入缓存，系统决定刷盘时机
  性能和安全性介于前两者之间，MySQL 挂了不会有数据丢失，但服务器宕机会损失 1 秒的数据。

如果 redo log Buffer 刷入磁盘后，数据库服务器宕机了，在下次重启的时候 MySQL 也会将 redo 日志文件内容恢复到 Buffer Pool 中，因为 redo log buffer 中的数据已经被写入到磁盘了，已经被持久化了。

Redis 的持久化机制类似，在 Redis 启动的时候会检查 rdb 或者是 aof 或者是两者都检查，根据持久化的文件来将数据恢复到内存中。

为什么要用redolog

在数据库系统中，数据的持久性和一致性是至关重要的。Redo Log 的引入正是为了确保这些目标的实现。以下是详细解释：

数据丢失问题

假设我们进行了一个修改数据的操作，数据修改后将数据缓存到 Buffer Pool 中。如果此时 MySQL 突然故障宕机，内存中的数据就会丢失，导致数据无法持久化到磁盘上。

在进行修改操作时，InnoDB 引擎会先更新内存（同时标记为脏页），然后将本次对这个页的修改以 Redo Log 的形式记录下来。当 MySQL 宕机后，再次恢复正常时，我们可以通过执行 Redo Log 中的操作来重新进行原来的修改操作。

Redo Log 能够实现事务的持久性，防止在发生故障时，有脏页未写入表的 ibd 文件中。在重启 MySQL 服务时，根据 Redo Log 进行重做，从而将未提交的事务进行持久化。这个过程可以简化为下图所示。

相信大家都知道 redo log 的作用以及它的刷盘时机和存储形式。

现在我们来思考一个问题：为什么不每次直接把修改后的数据页刷盘，而是要使用 redo log 呢？

1. 数据页大小与修改数据量不匹配
   数据页的大小是 16KB，刷盘操作比较耗时。而在许多情况下，修改的数据量可能只有几 Byte，这时候将整个数据页刷盘显得非常不划算。

2. 随机写操作性能差
   数据页刷盘是随机写操作，因为每个数据页在硬盘上的位置是随机的，这导致性能非常差。

3. Redo Log 的优势

   • 小而高效：一行记录可能只占几十 Byte，只包含表空间号、数据页号、磁盘文件偏移量和更新值。
   • 顺序写操作：Redo Log 是顺序写操作，因此刷盘速度非常快。

使用 Redo Log 记录修改内容，性能会远远超过直接刷数据页的方式，这也让数据库的并发能力更强。

MySQL 为了提高效率，先从磁盘读取数据放在内存中进行操作，然后在某个时机将其持久化到磁盘中。除了从磁盘中加载文件和将操作前的记录保存到 undo 日志文件中，其他的操作是在内存中完成的。

如果此时 MySQL 所在的服务器宕机了，那么 Buffer Pool 中的数据会全部丢失的。这个时候就需要 Redo 日志文件来恢复数据。

内存中的数据页在一定时机也会刷盘，我们称之为页合并。

Redo Log 的引入主要是为了提高数据库系统的性能和可靠性：

• 性能：通过顺序写操作和小数据量的写入，Redo Log 显著提升了写操作的效率。
• 可靠性：在系统故障时，Redo Log 确保了数据的持久性和一致性。

通过这些机制，MySQL 能够在高效处理事务的同时，确保数据的安全和完整。

mysql服务器宕机，缓冲区的数据会怎么样

在 MySQL 服务器宕机的情况下，缓冲区（Buffer Pool）中的数据会受到不同程度的影响，具体取决于数据的持久化状态。以下是详细的分析：

Redo Log 持久化前

• 事务失败：如果 Redo Log 尚未持久化到磁盘，那么 MySQL 会认为本次事务失败。
• Undo Log 恢复：利用 Undo Log 日志，MySQL 会将数据恢复到更新前的状态。这是因为 Undo Log 记录了数据在更新前的原始状态。

Redo Log 持久化后

• 事务成功：如果 Redo Log 已经持久化到磁盘，那么即使 MySQL 服务器宕机，数据修改也被认为是成功的。
• 重启恢复：在 MySQL 下次重启时，系统会自动将 Redo Log 文件中的内容恢复到缓冲区（Buffer Pool）中。这一过程确保了数据的持久性和一致性。

以下是更新过程的详细图示和步骤：

截至目前，我们应该都熟悉了 MySQL 的执行器调用存储引擎是怎么将一条 SQL 加载到缓冲池和记录哪些日志的，流程如下：

1. 准备更新一条 SQL 语句
2. MySQL（innodb）会先去缓冲池（BufferPool）中去查找这条数据，没找到就会去磁盘中查找，如果查找到就会将这条数据加载到缓冲池（BufferPool）中
3. 在加载到 Buffer Pool 的同时，会将这条数据的原始记录保存到 undo 日志文件中
4. innodb 会在 Buffer Pool 中执行更新操作，更新后的数据会记录在 redo log buffer 中
5. 将 redo log buffer 中的数据写入到 redo log 磁盘文件中(innodb_flush_log_at_trx_commit 参数决定)
6. 提交事务，数据修改永久保存到数据库

调用redolog的全过程

到此为止，从执行器开始调用存储引擎接口做了哪些事情呢？

从执行器开始调用存储引擎接口的全过程如下：

1. 准备更新：准备执行一条 SQL 更新语句。
2. 查找数据：MySQL（InnoDB 引擎）会先在缓冲池（Buffer Pool）中查找这条数据。如果缓冲池中没有找到，则会从磁盘中查找，并将数据加载到缓冲池中。
3. 保存原始记录：在加载到缓冲池的同时，会将这条数据的原始记录保存到 Undo 日志文件中。
4. 执行更新：InnoDB 在缓冲池中执行更新操作，更新后的数据会记录在 Redo Log Buffer 中。
5. 写入 Redo Log：MySQL 提交事务时，会将 Redo Log Buffer 中的数据写入到 Redo 日志文件中。
6. 刷盘策略：刷磁盘可以通过 innodb_flush_log_at_trx_commit 参数来设置刷盘策略。
7. 重启恢复：MySQL 宕机重启时，会将 Redo 日志恢复到缓冲池中。

有关redolog的问题解答

1. 什么是WAL技术, 好处是什么.

• WAL，中文全称是Write-Ahead Logging，它的关键点就是日志先写内存，再写磁盘。MySQL执行更新操作后，在真正把数据写入到磁盘前，先记录日志。
• 好处是不用每一次操作都实时把数据写盘，就算crash后也可以通过redo log恢复，所以能够实现快速响应SQL语句。

2. redo log 为什么可以保证crash safe机制呢？

Crash safe（崩溃安全）是指系统在发生崩溃（如电源故障、硬件故障、软件错误等）后，能够恢复到一致且正确的状态的能力。

• 因为redo log每次更新操作完成后，就一定会写入的，如果写入失败，说明此次操作失败，事务也不可能提交。
• redo log内部结构是基于页的，记录了这个页的字段值变化，只要crash后读取redo log进行重放，就可以恢复数据。

---

感谢大家的观看！！！创作不易，如果觉得我写的好的话麻烦点点赞👍支持一下，谢谢！！！
相关文章已在掘金发布，体验更佳！！