Doublewrite Buffer仅在写入脏页和崩溃恢复时起作用，读取数据页时完全不参与；InnoDB读取时直接从.ibd等数据文件加载页到Buffer Pool，不经过Doublewrite Buffer，也不用其校验或缓存。
Doublewrite Buffer 在读取数据页时完全不参与，它只在写入脏页时起作用。
Doublewrite Buffer 不处理读请求
InnoDB 读取数据页时，直接从磁盘文件（如 .ibd）加载页到 Buffer Pool，全程绕过 Doublewrite Buffer。它既不缓存读取内容，也不校验读取过程——校验只发生在崩溃恢复或页加载后的校验和验证阶段，且此时用的是页自身的 page checksum，不是 Doublewrite Buffer 中的副本。
常见误解是认为 Doublewrite Buffer 类似于“读缓存”或“一致性检查中间层”，实际它连读路径的边都沾不上。
什么情况下会访问 Doublewrite Buffer？
只有 MySQL 启动时做崩溃恢复，或后台线程检测到某页校验失败（innodb_checksum_algorithm != 'none' 且页头/页尾校验和不匹配），才会去磁盘上的双写文件（ib_dblwr_* 或系统表空间中对应区域）查找该页的完整副本。
- 触发条件必须是：页已加载进内存 + 校验失败 +
innodb_doublewrite = ON（或DETECT_AND_RECOVER） - MySQL 8.0.20+ 会先尝试从
ib_dblwr_1、ib_dblwr_2等双写文件读；旧版本则从ibdata1的固定偏移处读 - 读取成功后，用副本覆盖损坏页，再应用
redo log—— 这个“读”是恢复逻辑的一部分，不是常规查询路径
为什么不能用 Doublewrite Buffer 加速读？
Doublewrite Buffer 的磁盘布局虽为顺序写优化，但它的定位是“灾难备份区”，不是缓存层：
- 副本不是按主键/索引组织，无法支持随机读取定位
- 同一数据页可能在 Doublewrite Buffer 中存在多个历史副本（取决于刷脏频率），没有版本管理
- 内存中的 Doublewrite Buffer（2MB 固定大小）仅用于暂存待刷出的页，不保留历史页，且不对外提供读接口
- 启用
O_DIRECT或innodb_flush_method = O_DIRECT_NO_FSYNC时，甚至跳过部分 fsync，进一步削弱其作为可靠读源的资格
真正影响读性能的是 Buffer Pool 命中率、磁盘 I/O 调度、以及页压缩等机制；把 Doublewrite Buffer 当成读优化手段，只会误判瓶颈所在。
