doublewrite buffer不参与事务原子性保证，仅确保16kb数据页刷盘时的完整性；它独立于undo log和redo log，不记录逻辑变更、不支持回滚或重放，只防止部分页写入导致的页损坏。
双写缓冲区（Doublewrite Buffer）不参与事务原子性保证，它只负责页级写入完整性，和事务的“全做或全不做”无关。
Doublewrite Buffer 和事务原子性是两套独立机制
很多人看到“doublewrite”“buffer”“log”就下意识联想到事务日志，但 Doublewrite Buffer 既不是 redo log，也不是 undo log，它不记录任何逻辑变更、不保存旧值、不参与回滚或重放。它的唯一职责是：防止 16KB 的 InnoDB 数据页在刷盘时被截断成“半新半旧”的损坏状态。
事务原子性由 undo log 和 redo log 共同保障：
-
undo log记录修改前的镜像，支撑ROLLBACK回退到事务开始前 -
redo log记录物理页变更，支撑崩溃后重放未落盘的已提交事务 -
Doublewrite Buffer不感知事务边界，也不区分“已提交”或“未提交”，它只是把脏页拷贝一份再顺序写一次
为什么关闭 innodb_doublewrite 不影响原子性？
你可以用下面命令临时关闭它：
SET GLOBAL innodb_doublewrite = OFF;
此时事务依然能正常提交、回滚、崩溃恢复——只要 redo log 和 undo log 完整，原子性就不受影响。但风险在于：一旦发生部分页写入（partial page write），比如写到第 3 个 4KB 文件系统页时断电，该数据页校验和失效，InnoDB 启动时直接拒绝加载，redo log 也无法修复——因为重做日志只描述“如何改”，不提供“改成什么样”的完整页副本。
换句话说：
- 原子性失败场景：事务中途崩溃 → 靠
undo log回滚 - Doublewrite 失效场景：页写一半断电 → 导致数据文件损坏，可能引发启动失败或静默数据错误
MySQL 8.0 中 doublewrite 文件位置与配置变化
MySQL 8.0 将 doublewrite buffer 从共享表空间 ibdata1 拆出为独立文件，默认路径是 ./#ib_16384_0.dwb 和 ./#ib_16384_1.dwb（数字随 innodb_doublewrite_files 变化）。这意味着：
- 查看当前配置必须用：
SHOW VARIABLES LIKE 'innodb_doublewrite%'; - 修改
innodb_doublewrite_buffer_size后需重启 MySQL 才生效（它是只读变量） -
innodb_doublewrite_files在 8.0.20+ 才可用，设为 4 能缓解高并发刷脏页时的 I/O 竞争
注意：即使启用了多文件，每个脏页仍只会写入其中一个 doublewrite file，不是轮询或分片——它的作用仍是“先存一份完整副本”，而非提升吞吐。
真正容易被忽略的是：Doublewrite Buffer 的保护范围仅限于数据页刷盘那一刻；它不覆盖 redo log 写入、undo log 分配、binlog 刷盘等任何其他环节。一个页没坏，不代表事务没丢——比如 sync_binlog=1 和 innodb_flush_log_at_trx_commit=1 没配齐，照样会丢已提交事务。
