innodb_doublewrite默认强制启用，因其是防torn page的底线安全机制而非性能开关；大小固定128页（2MB），硬编码不可配置；MySQL 8.0.26+起该变量为只读，SET GLOBAL会报ERROR 1238。
innodb_doublewrite 默认启用，是因为它不是性能开关，而是防页断裂的底线安全机制；它的大小根本不能配置——固定 128 页（默认 2MB），硬编码在 InnoDB 内核里，所有试图调 innodb_doublewrite_buffer_size 的操作都无效。
MySQL 8.0 中 innodb_doublewrite 为什么强制 ON？
这不是“推荐开启”，而是设计上不允许绕过：从 8.0.26 起，innodb_doublewrite 变成只读变量，SET GLOBAL innodb_doublewrite = OFF 直接报错 ERROR 1238 (HY000): Variable 'innodb_doublewrite' is a read only variable。原因很直接：
• 16KB 页在多数文件系统中需拆成 4 次 4KB 写入，断电极易产生 torn page
• redo log 无法修复物理结构损坏的页，没双写副本就只能报 InnoDB: Database page corruption on disk 并拒绝启动
• 即使跑在 NVMe 或 RAID 10 上，也不能替代该机制——原子写仅保证块级，不覆盖页级部分写风险
innodb_doublewrite_buffer_size 是个伪参数
你在文档、博客或配置模板里看到的 innodb_doublewrite_buffer_size，MySQL 官方根本不认。InnoDB 硬编码双写缓冲区为 128 个页，按默认 innodb_page_size = 16384 算就是 2MB，位置在系统表空间起始处（8.0.20+ 后迁移到独立 .dblwr 文件）。
• SHOW VARIABLES LIKE 'innodb_doublewrite%' 查不到这个变量名
• 配置文件里写了也加载失败，mysqld 启动时静默忽略
• 源码里搜索 doublewrite_buffer_size 找不到对应逻辑
真正可调、且影响双写行为的参数只有三个
别在“大小”上浪费时间，该调的是路径、分布和模式：
• innodb_doublewrite_dir：指定双写文件存放目录，应设为低延迟设备（如 NVMe 上的独立路径），避免与 ibdata1 或 redo log 争盘
• innodb_doublewrite_files（8.0.30+）：控制双写文件数量（默认 2，范围 2–64），仅缓解高并发下 IO 锁竞争；单 SSD 设 >2 反而因小 IO 分散拖慢吞吐
• innodb_doublewrite 的值本身：除 ON/OFF 外，8.0.30+ 新增 DETECT_AND_RECOVER（等同 ON）和 DETECT_ONLY（只写元数据，无恢复能力，慎用）
验证双写是否真生效，别只看配置
配置文件写了 innodb_doublewrite = ON 不代表它在干活：
• 运行时查状态：SHOW VARIABLES LIKE 'innodb_doublewrite'; 必须返回 ON
• 看计数器是否增长：SHOW STATUS LIKE 'Innodb_dblwr%'; 中 Innodb_dblwr_writes 和 Innodb_dblwr_pages_written 应随 checkpoint 触发而递增
• 检查文件结构（8.0.20+）：SELECT * FROM information_schema.INNODB_TABLESPACES WHERE NAME = 'mysql/innodb_doublewrite';
• 启动日志里搜 Doublewrite files created 或 Doublewrite buffer 关键字
双写缓冲区的设计意图从来不是让你调大小或关开关，它是 InnoDB 在存储不可靠前提下守住数据页完整性的最后一道防线。所有“优化性能”的尝试，如果以关闭或绕过它为代价，本质上是在拿数据可用性换毫秒级写入延迟——而这种交换，在真实 OLTP 场景中几乎从不成立。
