doublewrite buffer解决的是“部分页写入”问题：因底层存储原子写入单元（512b/4kb）小于innodb页（16kb），断电可能导致页半新半旧、校验失败，而redo log无法修复结构损坏的页，故需双写区提供完整页副本用于崩溃恢复。
Doublewrite Buffer解决的是“部分页写入”这个物理层问题
InnoDB 默认页大小是 16KB，但底层存储设备（如 SATA SSD、HDD）的原子写入单元通常是 512B 或 4KB。这意味着一个完整的页写入必须拆成多个物理 I/O 操作。一旦在中途断电或进程崩溃，就可能出现“只写了前 8KB，后 8KB 还是旧数据”的情况——这个页就损坏了，校验和失效，InnoDB 启动时直接拒绝加载。
而 redo log 只记录“逻辑变更”，比如“把 ID=1 的 balance 加 100”，它无法修复一个结构已乱的页。没有完好的原始页，redo 就无从应用。这就是 Doublewrite Buffer 存在的根本原因：它提供一份可信赖的、完整的页副本。
为什么不能只靠 fsync 或 O_DIRECT 就绕过 Doublewrite？
即使设置了 innodb_flush_method=O_DIRECT，也不能避免部分页写入。因为 O_DIRECT 绕过 OS 缓存，但不改变磁盘控制器/固件对写入的分块行为；fsync() 保证的是“数据已落盘”，但不保证“整页原子落盘”。很多存储设备在掉电瞬间仍可能完成部分扇区写入。
-
O_DIRECT_NO_FSYNC更危险：跳过 fsync，双写缓冲区的磁盘副本本身都可能丢失 - 某些 NVMe 设备虽支持 16KB 原子写，但需确认硬件+固件+驱动全链路支持，且 MySQL 并不自动识别或依赖该能力
- 文件系统（如 ext4、XFS）也无法保证单次 write() 调用对应整页物理写入
MySQL 8.0.20+ 的双写文件 vs 旧版系统表空间
MySQL 8.0.20 起，双写缓冲区从 ibdata1 中剥离，改用独立文件（默认命名如 ib_dblwr_1、ib_dblwr_2）。这不是功能增强，而是解耦与运维便利性改进：
- 避免双写区域占用系统表空间头部空间，减少
ibdata1膨胀不可控风险 - 允许通过
innodb_doublewrite_files控制文件数量，提升高并发刷脏页时的并行写能力 - 删除或迁移双写文件更安全（只要实例未运行），不再需要导出整个系统表空间
- 但注意：
innodb_doublewrite_buffer_size仍是内存中缓冲区大小，默认2MB（128 × 16KB），它和磁盘上双写文件的总容量无关
DETCT_ONLY 和 OFF 的真实影响差异
innodb_doublewrite=OFF 是彻底关闭：既不写页内容，也不写元数据，崩溃后完全依赖 redo + 正常页恢复，遇到部分写失败即报错或丢数据。
innodb_doublewrite=DETECT_ONLY（MySQL 8.0.30+）是折中方案：
- 只写少量元数据（如页号、LSN、校验和）到双写文件，不写实际页数据
- 崩溃后无法用于修复损坏页，但能快速识别哪些页可能被部分写入，从而跳过校验直接重放 redo（避免因校验失败导致启动卡住）
- 适用于对延迟极度敏感、且底层存储已做强一致性保障（如企业级 SAN + 断电保护电容）的场景
- 切勿在普通云盘、本地 SATA SSD 上启用 —— 它不提供数据保护，只提供“更快失败”能力
真正容易被忽略的是：哪怕启用了 DETECT_ONLY，InnoDB 仍会分配内存中的 doublewrite buffer 空间，并执行 memcpy 拷贝操作 —— CPU 和内存开销并未减少，只是磁盘写入变轻了。
