不能安全禁用。mysql 8.0.26+ 中 innodb_doublewrite 是只读变量，运行时关闭被内核硬限制；配置文件设置无效，启动后仍为 on；所谓性能提升不可靠，真实场景几乎不可测，且禁用将导致断电时页损坏无法修复；应优化 innodb_doublewrite_pages、files、dir 及 flush_log_at_trx_commit 等参数。
不能安全禁用。 MySQL 8.0.26+ 中 innodb_doublewrite 是只读变量，SET GLOBAL innodb_doublewrite = OFF 必然报错：ERROR 1238 (HY000): Variable 'innodb_doublewrite' is a read only variable。所谓“安全禁用”本身就是一个伪命题——它不是性能开关，而是数据不崩溃的底线。
为什么 SET GLOBAL innodb_doublewrite = OFF 一定失败
这不是权限不足或配置遗漏，是内核级硬限制：
- MySQL 8.0.26 起彻底移除运行时关闭能力，无论实例是否全新、
innodb_page_size是否为 16384、innodb_undo_log_encrypt是否启用 - 即使你降级到 8.0.20–8.0.25，也仅在极苛刻条件下（全新初始化 + 未启加密 + 未升级过）可能临时生效；任何升级过的实例重启后都会被强制覆盖为
ON - 配置文件里写
innodb_doublewrite = OFF会被忽略，启动日志中不会出现双写文件创建提示，SHOW VARIABLES LIKE 'innodb_doublewrite'仍返回ON
禁用 doublewrite 带来的“性能提升”根本不可靠
所谓“降低 10%～15% 写放大”仅出现在人工可控的基准测试中，真实 OLTP 场景下几乎测不出来：
- 双写区写入是顺序 I/O + 单次
fsync()，瓶颈不在它，而在磁盘延迟和 redo log 刷盘策略 - 关掉它后，随机写稳定性下降，SSD 的写放大反而可能上升，寿命压力加大
- 一旦断电，
InnoDB: Database page corruption on disk或启动卡在Doublewrite buffer not found是分分钟的事，且redo log完全无法修复断裂页
真正可调、且影响写入性能的三个参数
别碰 innodb_doublewrite，去优化它背后的 I/O 行为：
-
innodb_doublewrite_pages：每批次写入双写文件的页数。默认值 =innodb_write_io_threads（通常为 4），导致fsync()次数暴增；大批量导入前务必设为64 -
innodb_doublewrite_files：控制双写页分散到几个独立文件（如#ib_16384_0.dwb）。默认为 2；高并发 + 多 NVMe 设备时可设为 4～8；单块 SSD 上设太高反而因小 IO 分散拖慢吞吐 -
innodb_doublewrite_dir：必须指向低延迟设备（如 NVMe SSD 上的独立目录），绝不能和ibdata1或redo log共盘——这是唯一能显著降低双写 I/O 延迟的实操点
真正拖慢导入速度的是 innodb_flush_log_at_trx_commit = 1 和 sync_binlog = 1 的同步叠加，不是 doublewrite 本身。想提批量写入性能，优先调这两个，而不是赌上数据完整性去碰 innodb_doublewrite。
