innodb所有数据变更必须在buffer pool中进行，无法直接修改磁盘页。因wal和mvcc机制约束，即使更新单个int字段，也需加载整页、加锁、写undo/redo、标记脏页；change buffer仅为非唯一二级索引的内存优化特例，仍属内存操作；直写磁盘会破坏redo/undo机制及并发控制。
因为InnoDB不支持直接修改磁盘页——所有数据变更都必须发生在Buffer Pool中，这是由其WAL（Write-Ahead Logging）和MVCC机制共同决定的硬性约束。
UPDATE语句根本无法绕过Buffer Pool
InnoDB的设计决定了它不会、也不能对磁盘上的页做“原地更新”。哪怕你只改一个INT字段，引擎也必须：
- 定位该行所在的16KB数据页（通过B+树查找）
- 检查该页是否已在
Buffer Pool中；若不在，触发同步IO从磁盘读取整页 - 在内存页上加行锁/间隙锁，写入
undo log，更新记录，标记该页为脏页
没有“跳过内存、直写磁盘”的路径。即使页已在Buffer Pool，也绝不是“顺便用一下”，而是唯一合法操作场所。
Change Buffer不是例外，而是特例中的特例
你可能听说“非唯一二级索引更新可以不加载数据页”，但这仅适用于Change Buffer场景，且有严格前提：
- 更新的是
非唯一二级索引（主键或唯一索引不适用） - 目标索引页当前
不在Buffer Pool中 - 事务已成功写入
redo log，但变更暂存于change_buffer而非数据页
注意：这仍是内存操作——只是换了个内存区域（change_buffer），并非跳过内存。后续首次访问该页时，仍需merge并加载进Buffer Pool。
为什么不能直接磁盘修改？三个硬性原因
直接写磁盘会破坏InnoDB的核心保障机制：
-
redo log无法按页粒度生成：WAL要求所有变更先记日志再改数据，而磁盘页无事务上下文 -
undo log无法构建：回滚依赖内存中旧值快照，磁盘页不具备版本链管理能力 - 并发控制失效：行锁、间隙锁、MVCC的可见性判断全部基于Buffer Pool中页的内存状态
哪怕强制用FLUSH TABLES FOR EXPORT或ALTER TABLE ... DISCARD TABLESPACE之类命令，也只是导出/替换整个表空间文件，不等于“单行直写磁盘”。
真正容易被忽略的点是：Buffer Pool不只是缓存，它是InnoDB执行引擎的“工作台”。没加载到内存，就等于没开工——不是慢，是根本不允许发生。
