MySQL 8.0升级后磁盘I/O飙升的隐蔽主因之一是innodb_doublewrite行为收紧：8.0默认对doublewrite buffer执行fsync且校验更严格，而5.6仅普通写、容错宽松；若磁盘延迟高，该环节易成I/O瓶颈，需结合硬件能力调优而非直接关闭。
innodb_doublewrite 配置不当，是 MySQL 5.6 升级到 8.0 后磁盘 I/O 突然飙升的隐蔽主因之一——不是它“变慢了”，而是它“被强制更严格地用了”。
innodb_doublewrite 在 5.6 和 8.0 中的行为差异
MySQL 5.6 默认开启 innodb_doublewrite，但实现较松散：
- doublewrite buffer 写入使用普通写（非 fsync）
- 崩溃恢复时容忍部分页损坏（尤其在机械盘 + 高并发写场景下可能静默跳过校验）
MySQL 8.0 对数据一致性要求更高：
- doublewrite buffer 写入默认触发
fsync()（尤其配合innodb_flush_method=O_DIRECT时） - 每次刷脏页前必须先落 doublewrite，且校验失败直接报错、拒绝写入
- 若磁盘延迟高（如旧 SSD 或 RAID 卡未调优），该环节会成为 I/O 瓶颈点，
iostat -x 1可见%util持续 100%，await显著升高
升级后是否该关闭 innodb_doublewrite
不建议直接关闭，除非你明确接受以下风险：
-
innodb_doublewrite = OFF时，页写入中断（断电、OS crash）可能导致单页损坏，InnoDB 无法修复，表损坏概率上升 - MySQL 8.0 的数据字典全部存于
mysql.ibd，该文件一旦损坏，实例无法启动 - 关闭后
SHOW ENGINE INNODB STATUS中的 “Doublewrite buffer usage” 统计归零，但Innodb_dblwr_writes状态变量仍可能非零（说明内核仍在尝试写，只是被忽略）
更稳妥的做法是：
- 确认存储硬件支持原子写（如 NVMe 支持
atomic writes），可设innodb_doublewrite = ON+innodb_doublewrite_pages = 8（减小每次刷写粒度） - 若用 SATA SSD 或虚拟化环境，改用
innodb_doublewrite = ON+innodb_doublewrite_log_write_size = 2M（8.0.20+），降低日志刷盘频率 - 避免与
sync_binlog = 1+innodb_flush_log_at_trx_commit = 1同时启用——三重 fsync 叠加极易打满 I/O
如何快速验证是否是 doublewrite 导致 I/O 异常
执行以下命令比对升级前后行为：
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_dblwr_writes';
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_dblwr_pages_written';
Innodb_dblwr_pages_written 是 Innodb_dblwr_writes 的 100 倍以上（例如前者 500 万，后者 5 万），说明 doublewrite buffer 溢出严重，正在高频 flush——这往往意味着 innodb_doublewrite_batch_size（8.0.30+）过小或磁盘响应太慢。
真正需要盯住的，不是“开不开”，而是“它现在每秒往磁盘塞了多少页、花了多少毫秒”。I/O 爆表从来不是配置开关的问题，而是硬件能力与一致性策略之间的摩擦点。
