MySQL断电“不丢数据”需Doublewrite Buffer与Redo Log协同：前者防半页写损坏，后者保证事务持久性；仅当innodb_doublewrite=ON且innodb_flush_log_at_trx_commit=1时才构成基本防护闭环。
MySQL断电后“不丢数据”不是默认保障，而是依赖Doublewrite Buffer + Redo Log协同工作
很多人误以为只要用InnoDB，断电就绝对安全。其实不然——innodb_doublewrite 必须为 ON（默认开启），且 innodb_flush_log_at_trx_commit = 1，才构成基本防护闭环。否则，即使有Redo Log，也可能因页损坏导致恢复失败。
为什么需要Doublewrite Buffer：防“半页写”（partial page write）
MySQL数据页大小是16KB，而文件系统（如ext4、XFS）的原子写单位通常是4KB。断电可能发生在页刷盘的第2个或第3个4KB块写入后，造成磁盘上存一个“撕裂页”（torn page）：前半页是旧数据，后半页是新数据，整个页逻辑损坏。
这种损坏无法靠Redo Log修复——因为Redo Log只记录“怎么改”，不记录“改之前长啥样”。没有原始页，重放日志就无从谈起。
-
Doublewrite Buffer是InnoDB在共享表空间中预留的一段连续1MB区域（128个页），所有刷盘前的数据页先顺序写入这里 - 写完Doublewrite Buffer后，再并行写入真正的数据文件位置
- 崩溃恢复时，InnoDB会扫描Doublewrite Buffer，若发现某页在数据文件中损坏，但Doublewrite里有完整副本，就用它覆盖修复
Doublewrite Buffer失效的典型场景
它不是万能盾牌，以下情况会让它失去作用：
- 磁盘本身故障（如坏道）导致Doublewrite Buffer区域也写失败——此时连“备份页”都丢了
- 手动关闭：
SET GLOBAL innodb_doublewrite = OFF或启动时配置为OFF，断电后页损坏概率陡增 - 使用某些特殊文件系统（如ZFS with disabled sync）绕过fsync，使Doublewrite Buffer未真正落盘
- SSD/Firmware bug 导致写入乱序，让Doublewrite Buffer和主数据区同时处于中间态
验证Doublewrite Buffer是否生效的实操方法
别只信配置项，要确认它真在运行：
- 查状态变量：
SHOW GLOBAL STATUS LIKE 'Innodb_dblwr%';—— 关注Innodb_dblwr_writes（实际写入次数）和Innodb_dblwr_pages_written（写入页数），非零即有效 - 检查错误日志：启动时若看到
InnoDB: Doublewrite buffer not found，说明初始化失败，需排查磁盘空间或权限 - 模拟页损坏（仅测试环境）：用
dd手动破坏一个.ibd文件中的某页，重启MySQL，观察是否自动从doublewrite区恢复该页（需开启innodb_force_recovery=0）
最常被忽略的一点：Doublewrite Buffer只保护数据页，不保护undo页、redo页、系统表空间头等关键结构。这些部分的损坏仍可能导致实例无法启动——所以它只是“页级可靠性”的关键一环，不是全链路保险。
