Buffer Pool本质是InnoDB默认全程介入的内存代理，缓存数据页和索引页以减少磁盘IO：读操作命中即内存返回，未命中才加载整页；写操作仅改内存并标记脏页，由后台异步刷盘；命中率低于99%将显著增加磁盘延迟。
Buffer Pool 本质是“内存代理”，不是缓存开关
它不靠“开/关”起作用，而是默认全程介入所有读写——只要数据页没在 Buffer Pool 里，InnoDB 就必须去磁盘加载；一旦加载进来，后续操作就只在内存里完成。所谓“减少磁盘 I/O”，其实是把原本每次都要跑磁盘的动作，压缩成仅首次加载那一次。
读操作：命中即免 IO，未命中才触发磁盘加载
执行 SELECT 时，InnoDB 先查 Buffer Pool 中是否存在对应数据页（按表空间 ID + 页号定位）。命中直接返回；未命中则触发一次物理读，把整页（16KB）从磁盘载入 Buffer Pool，再返回数据。
- 命中率低于 99% 时，每百次查询就有 ≥1 次真实磁盘读——而 HDD 随机读延迟约 10ms，SSD 也需 0.1ms，远高于内存纳秒级访问
- 全表扫描会把大量冷数据页塞进 Buffer Pool，挤出热点页，导致后续业务查询频繁 Miss（LRU 污染），监控
innodb_buffer_pool_reads和innodb_buffer_pool_read_requests才能发现 - 不要依赖“加了索引就一定快”：若索引不在 Buffer Pool 里，查索引本身也要先读磁盘；覆盖索引能进一步避免回表，等于省掉第二次页加载
写操作：只改内存页，脏页异步刷盘
执行 UPDATE 或 INSERT 时，InnoDB 只修改 Buffer Pool 中的页，标记为 dirty，并不立刻写磁盘。刷盘由后台线程（page cleaner）按 checkpoint 机制异步完成。
- 这把随机写转化成了顺序写 redo log，并延迟了数据页落盘时机，极大缓解写 I/O 压力
- 但若
innodb_buffer_pool_size过小，脏页积压多、淘汰频繁，反而引发集中刷盘（flush_list拥塞），表现为Innodb_buffer_pool_wait_free上升 -
innodb_flush_log_at_trx_commit = 1保证事务安全，但每次 commit 都 fsync redo log；设为 2 时只写 OS buffer，I/O 降但崩溃可能丢 1 秒数据
Buffer Pool 大小和结构直接影响 IO 效率
Buffer Pool 不是越大越好，也不是简单堆内存——它由 free list、flush list、LRU list 三个链表协同管理，每个缓存页还带约 800 字节控制块。配置不当会导致锁争用或内存浪费。
-
innodb_buffer_pool_size建议设为物理内存的 70–80%，但必须预留至少 2–4GB 给 OS 和连接线程，否则会触发 swap - 大 Buffer Pool（如 >12GB）务必启用
innodb_buffer_pool_instances = 8，否则单个 LRU mutex 成瓶颈，高并发下buffer pool mutex waits显著上升 - 重启后 Buffer Pool 为空，首次查询极慢；开启
innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup可实现热启动
