它是数据库（尤其是像 MySQL 的 InnoDB 引擎）中非常关键的一个机制，主要用来保证 事务的持久性（Durability）。
一、为什么需要 redo log？
想象一下：你向数据库插入一条数据，比如：
INSERT INTO users (name, age) VALUES ('Alice', 25);这个操作要写入磁盘上的数据文件（比如 users.ibd）。但磁盘 I/O 很慢，如果每次操作都直接写入数据文件，性能会很差。
而且，万一在写入过程中数据库崩溃了（比如断电），这条数据可能只写了一半，那就“丢数据”了！
所以数据库引入了一个 先写日志（Write-Ahead Logging, WAL） 的策略：
先写日志，再写数据。
而 redo log 就是这个“日志”。
二、redo log 到底是什么？
redo log 记录的是“物理修改”：它不是记录 SQL 语句，而是记录“某个数据页的哪个位置被改成了什么值”。
例如：“将 page 100 的偏移量 200 处的 4 字节从 0x00000000 改为 0x00000019”。
它是 循环写入 的：redo log 有固定大小（比如 4 个 1GB 的文件），写满后会覆盖旧的日志（前提是这些日志对应的修改已经刷到磁盘了）。
它是 顺序写 的，速度非常快（比随机写数据文件快得多）。
三、举个例子
假设你执行了上面的 INSERT 语句：
InnoDB 先在内存中的 Buffer Pool 里修改数据（还没写磁盘）。
同时，InnoDB 把这次修改的 物理变化 写入 redo log（并标记为“未刷盘”）。
事务提交时，只要 redo log 成功写入磁盘（fsync），事务就算成功了！即使此时数据文件还没更新。
后台线程会在合适时机把内存中的脏页（dirty page）刷到磁盘的数据文件中。
如果数据库崩溃重启，InnoDB 会 重放（replay）redo log，把没来得及写入数据文件的修改重新应用一遍，保证数据不丢。
✅ 这就是 crash-safe（崩溃安全） 的核心机制！
四、和 binlog 有什么区别？
五、总结一句话
redo log 是 InnoDB 为了快速、安全地保证事务持久性而设计的一种“物理修改日志”，在崩溃后可以通过它恢复未刷盘的数据。
评论