MySQL--写入过程与关键组件(Buffer Pool&Redo Log Buffer)-CSDN博客

先来看一张图解

1. 关键组件介绍

🔹 Buffer Pool

是什么：InnoDB 的内存缓存区，存放 数据页（16KB） 和 索引页。

作用：

加速读：把常用数据页放在内存中，避免频繁磁盘随机读。

加速写：修改数据时，先写 Buffer Pool，而不是直接写磁盘。

通过“脏页机制”实现 批量落盘，减少磁盘随机写。

以页为单位刷盘

👉 为什么需要 Buffer Pool？
因为直接操作磁盘页是 随机 I/O，非常慢。Buffer Pool 把随机写转化为内存操作，再批量写回磁盘，大幅提升性能。

🔹 Redo Log Buffer

是什么：内存中的 Redo Log 缓冲区。

作用：

当事务执行时，先把日志写入 Redo Log Buffer（内存）。

再由后台线程（或事务提交时）把 Buffer 中的日志 顺序写入磁盘上的 Redo Log 文件。

👉 为什么需要 Redo Log Buffer？
因为每次事务写磁盘会很慢，先写入 Buffer（内存快），再批量顺序写到磁盘，性能更高。

👉 为什么写入Redo Log需要 Redo Log Buffer呢，直接由Buffer Pool写入Redo Log不就好了？

(1)InnoDB 的 Buffer Pool 在刷脏页到磁盘时，确实是“以页（Page）为单位”写回的，而不是只更新某一行或某几个字节。所以即便你只更新了一行或一个字段，Buffer Pool 里标记脏页后，刷盘时还是要把整个页写回磁盘。

(2)InnoDB 的 Redo Log Buffer 写的是对页的修改记录（操作日志）所以Redo Log Buffer 写入 Redo Log 时，并不是整页，而是记录 “页的某些位置被改动”，只写必要的修改信息。

🔹 Redo Log（重做日志）

是什么：磁盘上的日志文件（物理日志），记录“对数据页的物理修改”。

作用：

保证 事务的持久性（D）：即使宕机，数据也能通过 Redo Log 恢复。

避免事务提交时必须立即把脏页写回磁盘。

👉 特点：顺序写磁盘，比随机写快很多。

🔹 Binlog（归档日志）

是什么：MySQL Server 层的日志（逻辑日志），记录的是 SQL 语句或行的变化。

作用：

用于 主从复制、数据恢复。

和 Redo Log 一起保证事务的完整性。

2. 一次插入操作的完整流程

假设执行：
INSERT INTO user(id, name) VALUES(1, 'Tom');
执行流程如下：

写入 Buffer Pool

找到目标数据页，如果不在内存 → 从磁盘加载到 Buffer Pool。

在 Buffer Pool 中修改数据页（内存操作，快）。

把该页标记为脏页。

写入 Redo Log Buffer

记录这次对数据页的修改（物理日志），写入 Redo Log Buffer。

此时修改已经在内存里，Redo Log Buffer 也有记录。

写入 Redo Log（顺序写磁盘）

事务提交时，把 Redo Log Buffer 刷到磁盘上的 Redo Log 文件。

至此，事务具备了 崩溃可恢复性。

写入 Binlog（归档日志）

把这条 SQL 或行变更写入 Binlog（逻辑日志，用于复制/恢复）。

两阶段提交

为了保证 Redo Log 和 Binlog 的一致性，MySQL 采用“两阶段提交”：

先写 Redo Log（prepare 状态）；

再写 Binlog；

最后提交 Redo Log（commit 状态）。

脏页刷新（异步）

脏页不会立即写回磁盘，而是后台线程异步、批量写回（减少随机写）。

3. 随机写 vs 顺序写

磁盘随机写：修改不同数据页时，磁盘需要频繁寻址，速度慢。

磁盘顺序写：日志文件追加写，不需要频繁寻址，速度快。

👉 对应关系：

Buffer Pool：解决随机写慢的问题（把修改先写内存，再批量落盘）。

Redo Log Buffer + Redo Log：通过顺序写保证事务持久性，提升提交效率。

4. 总结一句话

Buffer Pool → 解决随机写慢（把随机写变成内存操作 + 批量落盘）。

Redo Log Buffer → 解决日志写入慢（先写内存，再批量顺序写磁盘）。

Redo Log → 保障事务持久性。

Binlog → 保障数据恢复与复制。