redo log

核心作用

1.保证数据安全 事务提交不会丢失数据（崩溃恢复，解决的一个问题 ：Buffer Pool里的脏页还没有落盘 系统宕机怎么办？）
2.提升数据写入速度，把随机IO变成顺序IO（WAL机制）

DML → 改内存（脏页）→ 写 redo log （redo log 刷盘（commit关键点））→ redo log成功 → 事务提交成功 → IO线程择机刷脏页 → checkpoint推进 → checkpoint之前redo log可覆盖

在“正常 commit 成功返回”的前提下：

redo log 已经“持久化到磁盘路径（disk）”，不会丢失（在数据库层面保证）不会丢失”是数据库语义保证，不是物理世界 100% 保证，取决于 innodb_flush_log_at_trx_commit，1（强制提交，默认的最安全，TPS最低）2（写入OS cache） 0（每秒写一次）

只有当 checkpoint 已经确认对应 redo log 所记录的数据都已落盘后，这部分 redo log 才可以被复用覆盖

组件	本质
redo log	保证事务持久性
脏页	内存修改结果
checkpoint	数据安全边界

为什么 redo log 不设计成可读？

✔ 1. 性能优先

redo log 必须：

顺序写
极快
不能解析 SQL
✔ 2. 存储空间小

如果存 SQL：

太大
太慢
不适合 crash recovery
✔ 3. 它不是“审计日志”

它的定位是：

恢复用（recovery log）
不是
❌ 人类阅读日志

WAL 顺序写 vs 随机 IO 速度差距完整结论（分 HDD/SSD，数据库真实场景）

核心原理差距来源

随机写（直接刷数据页）：修改分散在不同数据页，磁盘要频繁寻道、旋转等待，延迟极高；
WAL 顺序写（redo/binlog）：只追加到日志文件尾部，连续块写入，几乎无寻道开销；
WAL 本质：把多条分散随机写，合并成单次日志顺序写，脏页后台批量异步刷盘。

对比

HDD：顺序写是随机写的100 倍以上，是 WAL 设计的根本驱动力；
SATA SSD：5–20 倍；
NVMe SSD：2–10 倍；
核心原因：随机写存在机械寻道 / 闪存 GC 写放大，WAL 追加式顺序写规避了所有零散 IO 开销。

undo log

一致性解读

事务执行前符合这套规矩，事务执行后也依然符合这套规矩，规矩从头到尾是统一的，数据始终和规矩对齐。数据状态 和 预先定义的约束 保持对齐
数据库能自动保证的，是和 “数据库内置约束”（主键、非空、唯一键、外键）保持一致
业务层面的一致性，需要开发者利用事务，自己保证和 “业务规则” 保持一致