MySQL Buffer Pool 是什么？数据修改后为什么不马上写入磁盘？

知识点详解：一次查询和一次修改，分别怎么经过内存页

先把一页数据想成一组记录的存放单位

假设任务表里连续几个任务位于同一个数据页。查询其中一个任务时，InnoDB 把需要的页读进 Buffer Pool；随后访问同页的其他记录，有机会直接利用这份缓存。

索引页也需要缓存。沿 B+ 树找记录时，缓存命中可以减少相关磁盘访问。至于某个查询还要查多少页，仍然取决于索引、筛选条件和读取列。

这和“保存 SELECT 的最终结果”不同。两条 SQL 可以复用同一个页，同一条 SQL 也可能需要读取大量不在缓存里的页。

修改在内存发生，脏页等待写回

例如把任务状态改为完成。内存中的页发生变化，磁盘上的那份还没跟上，此时页被标记为脏。

后续刷盘会把更新后的页写回磁盘。多个修改可能在一次页写回中体现出来，所以没有必要每改一个字段，就立刻把整页写一遍。

这里说的是物理页写回策略。事务何时提交、其他事务看见哪个版本，是另外的事务和隔离机制，不能用“还没刷页”推导成“其他人一定看不到”。

页没刷盘，日志先提供恢复依据

Buffer Pool 在内存里，断电会丢失。数据库要在可靠的持久化规则下保存 redo，使崩溃之后能够恢复需要保留的修改。

所以一次事务涉及内存页、日志缓冲、日志文件以及数据文件等不同对象。它们不是“提交按钮一按，同时全部写完”。写前日志要求相关日志在数据页持久化之前满足相应规则。

本文不把某个日志参数设定当作所有环境的默认保证。要承诺断电后的持久性，必须核对实际刷盘参数、存储设备和事务提交链路。

缓存越大越好，也有前提

缓冲区太小会频繁读盘；但给它分配过多内存，也可能挤压连接、排序、其他进程，甚至造成系统换页。

另外，批量扫描很少再访问的数据，会和热点页争缓存。InnoDB 使用改进的 LRU 管理，并提供扫描相关调节，不能简单当成“读过就永久保留”。

排查时把物理读取、缓存命中、待刷页和磁盘延迟一起看。如果请求每次都扫描大量页，先改查询往往比只加内存更直接。

本题机制参考：Buffer Pool、Redo log、刷盘配置。

面试官继续追问

重启以后 Buffer Pool 还能保留吗？

内存内容本身不能跨重启保留。页标识的导出与加载可以帮助预热，但不是把原来的内存和脏页状态完整保存下来。

命中率很高为什么接口还慢？

可能扫描了很多缓存页，也可能在等锁、做排序或处理结果。命中率只说明少了一部分磁盘读取，不代表查询总体便宜。

脏页很多一定是异常吗？

不一定。要结合写入速度、刷盘能力、检查点推进和延迟看趋势，不能只拿一个百分比下结论。

面试速记卡

• 对象：缓存页，不是缓存完整 SQL 结果。
• 脏页：内存版本比磁盘新，等待写回。
• 持久性：结合 redo 与实际刷盘规则。
• 管理：改进 LRU，不是永久保存所有读过的页。
• 调优：命中、刷盘、查询工作量和总内存一起看。