innodb_doublewrite 是 InnoDB 保证崩溃恢复时页写入原子性的底层机制，不可关闭；关闭会导致部分写失效、页面损坏及启动失败。
innodb_doublewrite 是什么，为什么不能关
它不是可选功能，而是 InnoDB 保证崩溃恢复时页写入原子性的底层机制。关掉 innodb_doublewrite，MySQL 在写入数据页中途崩溃（比如断电、OS kill），极大概率产生“部分写失效”（torn write）——磁盘上存的是半新半旧的页，恢复后直接报 Corrupted page 或启动失败。
常见错误现象：InnoDB: Database page corruption on disk、mysqld 启动卡在 recovery 阶段、查询返回乱码或 ERROR 2013 (HY000)。
- 默认开启（MySQL 5.6+），值为
ON或1；设为OFF属于高危操作，仅限调试环境且必须配合innodb_flush_method=O_DIRECT+ 硬件 RAID 缓存保护 - 开启后，InnoDB 不是直接写数据文件，而是先写到共享表空间里的 doublewrite buffer（连续 128 页），再批量刷到真正的数据文件；崩溃后靠 doublewrite buffer 中的完整副本重刷损坏页
- 性能影响真实存在：多一次写（约 10%~20% 写吞吐下降），但换来的是 crash-safe 的底线保障，别为这点吞吐赌数据
怎么确认 doublewrite 是否真在工作
光看配置项不保险，得查运行时状态和物理文件痕迹。
- 执行
SHOW VARIABLES LIKE 'innodb_doublewrite';，返回ON仅说明配置生效，不代表当前有效 - 查
SHOW ENGINE INNODB STATUS\G，在DOUBLEWRITE小节下找Doublewrite buffer not used—— 如果出现，说明 doublewrite 实际被绕过了（常见于innodb_page_size=64K且 OS 支持 atomic write 的极少数场景） - 用
ls -lh /var/lib/mysql/ibdata1看共享表空间大小：如果启用了 doublewrite，ibdata1里会包含 doublewrite buffer 区域（固定 2MB，128 页 × 16KB），文件尺寸应 ≥ 12MB（最小 ibdata1 默认含 3 个区）
SSD/NVMe 上要不要关 doublewrite 来提升性能
不要。现代 SSD 的“原子写”只对 512B/4KB 对齐的单次写有效，而 InnoDB 数据页是 16KB，且写入路径经过 page cache、buffer pool、log buffer 多层缓冲，无法保证端到端原子性。NVMe 设备仍会发生 torn write。
- MySQL 官方文档明确指出：
innodb_doublewrite在所有存储类型上都应保持启用 - 某些厂商宣传的“hardware atomic write support”需同时满足：设备固件支持、驱动暴露
BLKSECDISCARD、内核启用CONFIG_BLK_DEV_INTEGRITY，且 MySQL 编译时链接了对应 lib —— 当前主流发行版 MySQL 二进制包均未启用该路径 - 压测对比显示：关 doublewrite 后 QPS 提升有限（
事务不丢失 ≠ doublewrite 能单独搞定
doublewrite 只管数据页写入的完整性，不负责事务逻辑一致性。它和 innodb_flush_log_at_trx_commit、redo log、binlog 共同构成事务持久化链条。
-
innodb_doublewrite=ON+innodb_flush_log_at_trx_commit=0：事务提交后日志可能还在 OS cache，断电照样丢事务 —— doublewrite 救不了没刷盘的 redo -
innodb_doublewrite=ON+sync_binlog=0：主从切换时可能丢 binlog，导致从库数据缺失 —— doublewrite 不管 binlog 文件 - 真正防丢事务的最小安全组合是：
innodb_doublewrite=ON+innodb_flush_log_at_trx_commit=1+sync_binlog=1（注意：这三者叠加会显著降低写性能，需按业务容忍度权衡）
doublewrite 是地基，不是屋顶。它默默扛住最底层的硬件异常，但上面盖什么楼，还得你自己配好 redo 和 binlog 的砖瓦。配置错一层，就可能让这层地基白搭。
