Innodb Redolog、Undolog、BufferPool

MySQL的InnoDB引擎能保证数据安全和高效运行，核心离不开redo log（重做日志）、undo log（回滚日志）和Buffer（缓冲）刷盘机制。

一、redo Log 核心逻辑

redo log的设计初衷是解决“磁盘读写慢”与“数据持久化”的矛盾：磁盘读写速度远慢于内存，若每次修改数据都直接写磁盘，会严重影响性能；同时需避免数据库崩溃后已提交数据丢失，redo log由此而生。

1.1 Redo Log 的核心作用

• 一是保证事务持久性，防止数据库意外崩溃后已提交数据丢失。
• 二是提升写入性能，采用“顺序写”方式，速度远快于磁盘随机写。

核心依赖WAL（Write-Ahead Logging 先写日志）机制

事务提交时，先将修改记录写入redo log，再异步将数据刷到磁盘，兼顾数据安全与写入效率。

1.2 Redo Log 的核心特性

• 物理日志：记录数据页的物理修改（如“某数据页某位置值从A改B”），非逻辑操作；

• 循环写：固定大小，写满后覆盖旧日志（前提是旧日志对应数据已刷盘）；

• 先写后刷：事务提交时，强制将redo log从缓冲区刷到磁盘，数据则异步刷盘。

1.3 Redo Log 的写入流程

1. 执行修改操作（update、insert等），同步修改内存中buffer pool的数据页（变为脏页），同时将修改记录写入redo log buffer；

2. 事务提交时，将redo log buffer中的对应记录强制刷到磁盘redo log文件；

3. 后台线程异步将buffer pool中的脏页刷到磁盘数据文件（.ibd）。

1.4 关键细节：LSN

LSN（全称：Log Sequence Number，日志序列号）是全局唯一、递增的序列号，按修改操作顺序分配，非事务提交顺序。

每一条redo log记录、每一个buffer pool数据页，都会标记对应LSN，用于同步redo log与buffer pool的刷盘进度，判断日志是否可覆盖、数据是否已刷盘。

修改buffer pool数据页与写入redo log buffer是原子操作，要么同时成功，要么同时失败，避免中间状态。

二、redo Log 与 Buffer Pool 刷盘同步机制

redo log与buffer pool刷盘时机相互独立，通过LSN与checkpoint LSN实现同步，避免重复刷盘和数据不一致。

2.1 刷盘时机

• redo log刷盘（3种）：事务提交时强制刷盘、每1秒自动刷盘、redo log buffer满时自动刷盘；

• buffer pool刷盘（4种）：后台线程定时异步刷盘、buffer pool满时淘汰旧脏页刷盘、事务提交时间接刷盘、数据库正常关闭/重启时刷所有脏页。

2.2 同步逻辑

InnoDB维护checkpoint LSN，标记“所有小于该值的redo log，其对应数据已刷盘”。

若redo log的LSN ≤ checkpoint LSN，说明对应数据已刷盘，日志可被覆盖；若LSN ＞ checkpoint LSN，说明数据未刷盘，日志需保留，供崩溃后恢复。

redo log（重做日志）刷盘，是将redo log buffer中的记录刷到redo log日志文件，采用顺序写方式；

buffer pool（缓冲池）刷盘，是将内存中的脏页刷到.ibd数据文件（InnoDB的数据存储文件），由于数据页在磁盘上的分布是离散的，因此buffer pool刷盘属于随机读写，这也是其刷盘速度慢于redo log刷盘的核心原因。

三、崩溃恢复与回滚机制

数据库异常崩溃后，通过redo log恢复已提交数据，通过undo log回滚未提交数据，共同保证数据一致性。

3.1 Redo Log 恢复时机（自动触发）

• 异常崩溃重启：扫描redo log中“LSN＞checkpoint LSN且已提交”的记录，将未刷盘的已提交修改补刷到磁盘；

• 正常关闭后重启：按需补刷未刷盘的已提交脏页，确保数据一致。

3.2 Undo Log 核心逻辑

undo log的核心作用是事务回滚，并非专门为MVCC设计，仅在回滚时定位并恢复相关记录。

写入逻辑：先写入undo log buffer，再异步刷到磁盘undo表空间；未提交事务的undo log会刷盘暂存，提交后后台异步清理。

回滚触发时机：事务主动rollback、数据库异常重启后未提交事务、事务执行出错（如死锁）。

四、查询时的数据内存加载逻辑

MySQL查询采用按需加载模式，不一次性加载整表，提升查询效率。

• 仅加载数据页和索引页到buffer pool（默认16KB/页，即使只查一行也加载整页）；

• 加载流程：先查buffer pool（命中直接读）→ 未命中从磁盘加载→ 后续查询复用内存数据；

• 补充：内存仅存被访问过的页，通过LRU算法淘汰旧页；快照读（无锁读）读取buffer pool数据页的版本链（结合MVCC），无需直接读磁盘。

补充说明

MVCC（你提及的Mac c应为MVCC）本质是一个概念，核心实现依赖ReadView，而非Redis；Redis是独立的缓存中间件，与InnoDB的MVCC实现无关联。

redo log的设计核心是解决“性能与持久化”矛盾，undo log解决“事务回滚与一致性”，二者与buffer pool、LSN协同，构成InnoDB的核心运行机制。

总结

InnoDB各核心机制各司其职：redo log保障持久化与写入性能，undo log负责回滚，buffer pool减少磁盘IO，LSN同步刷盘与恢复进度，MVCC依赖ReadView实现并发读，共同支撑MySQL稳定高效运行。