innodb_doublewrite必须开启，它是防止partial page write导致页损坏的强制保障机制：16kb页被拆为多次4kb写入，断电易造成前新后旧的断裂页，使page checksum失效、redo log无法解析页头而失效，崩溃后只能依赖备份恢复。
innodb_doublewrite 必须保持开启，关掉它等于放弃页级数据完整性底线。这不是性能可选项，而是防止断电导致 Database page corruption on disk 报错、实例无法启动的强制保障机制。
为什么 partial page write 会让 redo log 失效
InnoDB 默认页大小是 16KB，而 Linux 文件系统以 4KB 为单位刷盘，老硬盘甚至用 512B 扇区。一次页写入要拆成 4 次底层 I/O。断电可能卡在第 2 次写完、第 3 次未开始的位置——结果就是磁盘上这个页前半截是新数据、后半截是旧垃圾值。
这种「断裂页」的 page checksum 必然校验失败。此时 redo log 完全无用：它只记录「对某页 offset X 执行了 SET Y=Z」，前提是页头能正常解析出 space_id 和 page_no；损坏页连事务 ID 都读不出来，redo 根本不知道该重放到哪。
- binlog 同样不救场：它只存逻辑变更（如
UPDATE t SET v=1 WHERE id=5），不存物理页副本 - 没有
doublewrite buffer，崩溃后唯一办法是恢复备份，且必然丢失最后几秒事务
Doublewrite Buffer 不是缓存，而是「先落副本、再写正本」的原子链
它的名字带 Buffer 容易误导，实际是「内存 + 磁盘」双层结构：
- 内存中：128 个
16KB页，共2MB，由memcpy快速拷贝脏页 - 磁盘上：MySQL 5.7 存在
ibdata1预留连续区域（extend1+extend2）；MySQL 8.0 起独立为dblwrlog文件 - 写入流程严格分三步：
memcpy→ 顺序写双写区（两次1MB，fsync保落盘）→ 再异步写入对应.ibd文件
关键点在于：双写区写入是顺序 I/O，开销远低于随机写；而崩溃恢复时，InnoDB 会扫描双写区，对每个校验失败的 .ibd 页，按 space_id+page_no 查找完整副本覆盖修复，之后才继续应用 redo log。
禁用 innodb_doublewrite 的真实代价和适用场景
innodb_doublewrite 默认为 ON，动态可调，但生产环境禁用风险极高：
-
DETECT_ONLY模式只写元数据，不存页内容，失去恢复能力，仅用于诊断部分写发生频率 -
OFF模式彻底关闭，适用于压测或临时测试库——但必须接受「断电即丢页」的事实 - MySQL 8.0.20 新增
innodb_doublewrite_dir，建议把双写文件放在 NVMe 盘，避免与.ibd争 IO
真正容易被忽略的是：即使你用了 O_DIRECT 或 innodb_flush_method=O_DIRECT_NO_FSYNC，双写缓冲区仍需保留——因为 O_DIRECT 绕过 OS 缓存，但不解决底层设备中断导致的 partial write。
