doublewrite 是 innodb 防止部分页写失效的核心机制：脏页先顺序写入双写缓冲区（2mb连续空间），fsync 持久化后再随机写入数据文件；崩溃时通过校验从双写区恢复完整页，确保数据一致性。
先更新 Buffer Pool，再异步刷盘——但靠这个本身无法保证一致性，真正起作用的是 WAL + Double Write + Checkpoint 三者协同。
为什么不能直接等 Buffer Pool 修改完再写磁盘？
因为随机磁盘 I/O 太慢。一次 UPDATE 可能只改一个字节，但 InnoDB 必须以 16KB 页为单位刷盘；如果每条语句都同步刷，吞吐量会断崖式下跌。所以 MySQL 选择“内存先行”，但必须配套日志和校验机制兜底。
常见错误现象：innodb_flush_log_at_trx_commit=0 时，断电可能丢最近 1 秒事务；innodb_doublewrite=OFF 时，部分页写入（Partial Page Write）会导致页损坏，mysqld 启动时可能报 InnoDB: Database page corruption 并拒绝启动。
- 性能影响：关闭
innodb_doublewrite能提升约 5–10% 写入吞吐，但崩溃后恢复失败风险显著上升 - 兼容性注意：某些云厂商托管 MySQL 实例强制开启
innodb_doublewrite，不可修改 - 关键参数：默认
innodb_flush_log_at_trx_commit=1，确保每次COMMIT都触发fsync()刷 redo log
WAL（Write-Ahead Logging）如何让内存修改“可恢复”？
WAL 不是“先写日志再改内存”的线性流程，而是“日志落盘优先级高于数据页落盘”。InnoDB 在修改 Buffer Pool 前，已将该操作的物理描述（如 page 1234, offset 567, write 'abc'）写入 redo log buffer，并在事务提交时按策略刷盘。
使用场景：主库宕机重启后，InnoDB 自动重放（replay）未应用到数据页的 redo log，把脏页“追平”到最新状态。这过程不依赖 binlog 或 undo log。
-
innodb_log_buffer_size默认 8MB，大事务（如批量UPDATE）可能触发提前刷盘，避免用户线程阻塞 - redo log 是循环文件（
ib_logfile0/ib_logfile1），大小由innodb_log_file_size控制；过小会导致频繁 checkpoint，拖慢写入 - 不要混淆：
redo log记录的是物理页变更，binlog记录的是逻辑 SQL，二者在二阶段提交中协同但职责分离
Double Write 怎么防止“写一半就断电”？
当 Buffer Pool 中的脏页要刷到磁盘时，InnoDB 不直接写 .ibd 文件，而是先顺序写入系统表空间（ibdata1）里的 Double Write 区域（连续 2MB）。只有这部分写成功，才开始写实际数据文件位置。
容易踩的坑：部分 SSD 或文件系统（如某些 XFS 配置）声称支持原子写 16KB，但 MySQL 仍默认启用 Double Write。禁用前务必验证底层存储是否真能保证页原子性，否则崩溃后可能读到半新半旧的损坏页。
- 查看状态：
SHOW STATUS LIKE 'Innodb_dblwr%'中Innodb_dblwr_writes应远大于 0 - 代价明确：Double Write 会让写放大（write amplification）接近 2 倍，但这是换取数据完整性的必要开销
- 修复逻辑：崩溃后若发现某页校验失败，InnoDB 会从 Double Write 区域拷贝完整副本覆盖损坏页
Checkpoint 如何控制脏页刷盘节奏？
Checkpoint 不是定时任务，而是由三个压力源共同驱动的动态点：Buffer Pool 空间不足（LRU 淘汰需刷脏页腾位）、redo log 快写满（必须推进 checkpoint 释放旧日志空间）、系统空闲（后台线程主动刷）。它本质是记录“哪些 redo log 已经对应到磁盘数据页”，缩小崩溃恢复范围。
性能/兼容性影响：innodb_max_dirty_pages_pct（默认 75%）设太高，可能堆积大量脏页，导致 checkpoint 突增 I/O；设太低，则频繁刷盘，浪费 SSD 寿命。
- 监控指标：
Innodb_buffer_pool_wait_free> 0 表示 Buffer Pool 紧张，急需刷脏页 - 不要手动干预：
FLUSH TABLES WITH READ LOCK或SET GLOBAL innodb_fast_shutdown=0会影响 checkpoint 行为，仅在停机维护时使用 - 真正“强一致”的边界在 redo log 落盘那一刻，而非脏页刷盘完成——后者只是清理内存、释放资源
最常被忽略的点：一致性不是单点保障，而是链条。比如你调高 innodb_log_file_size 降低 checkpoint 频率，却忘了同步调整 innodb_io_capacity，可能导致后台刷脏页跟不上，Buffer Pool 持续淤积脏页，最终拖慢所有写操作。每个参数都在链上咬合，改一个就得看全局。
