因为InnoDB以redo log落盘为持久化标志：事务提交时只需确保redo log写入磁盘（如ib_logfile0），崩溃重启后即可重放日志恢复数据，无需等待脏页刷盘。
MySQL 的 redo log 是 InnoDB 存储引擎实现事务持久性的核心机制，不是可选功能，而是崩溃后数据不丢的刚性保障。
为什么事务提交后数据还没写到磁盘，却算“已持久化”？
因为 InnoDB 不等脏页刷盘就返回成功——它只确保 redo log 已落盘。只要这条日志写进磁盘（比如 /var/lib/mysql/ib_logfile0），哪怕紧接着断电，重启时也能靠它把没来得及刷盘的修改重放一遍。
常见错误现象：UPDATE 执行成功、客户端收到 OK，但服务器突然宕机，重启后数据还在——这不是运气好，是 redo log 在起作用。
- 它记录的是“物理页变更”，比如“页号 1234、偏移量 567 处写入了新值 0xabc”
- 写入方式是顺序追加，比随机写数据页快得多
- 内存中先写
redo log buffer，事务提交时触发fsync刷盘（受innodb_flush_log_at_trx_commit控制）
innodb_redo_log_capacity 调大后为什么脏页刷得更慢？
这个参数（MySQL 8.0.30+）直接控制 redo 日志文件总容量上限。设为 8GB 并不等于立刻分配 8GB 磁盘空间，而是告诉 InnoDB：“你可以用这么多空间存未 checkpoint 的日志”。
调大后影响明显：
- InnoDB 会推迟 checkpoint，让
redo log文件保留更多未处理记录 - 缓冲池中脏页刷盘频率降低，减少 I/O 压力
- 但 crash recovery 时间可能变长（要重放的日志更多）
- 执行
SET GLOBAL innodb_redo_log_capacity = 8589934592后，实际空间占用会渐进调整，不是立即生效
和 binlog、undo log 混用时最容易踩什么坑？
三者层级不同、用途不同，但协同工作。出问题往往卡在配合环节：
-
binlog是 Server 层日志，用于主从复制；redo log是 InnoDB 层日志，只管崩溃恢复。主从切换时如果binlog和redo log位点不一致，可能丢事务 -
undo log记逻辑逆操作（如 “INSERT → DELETE”），redo log记物理变更（如 “页X偏移Y写入Z”），二者不是互为镜像，不能互相替代 - 双写机制（
doublewrite buffer）和redo log是两套防线：前者防页写半页损坏，后者防整个实例崩溃。关掉doublewrite不影响redo log功能，但会放大介质故障风险
真正关键的细节不在文档里，而在配置与行为的耦合处：比如 innodb_flush_log_at_trx_commit=2 时日志只写 OS 缓存，依赖系统定时刷盘——这在云主机上可能因内核调度延迟导致意外丢失；又比如 redo log 文件大小固定、循环覆盖，checkpoint 落后太多会触发强制刷脏页，瞬间拉高 I/O。这些不是理论，是线上抖动的常见源头。
