innodb缓冲池是读写必经主干道，非可选优化项；它以16kb页为单位缓存数据、索引等，通过free、lru（分young/old区）、flush三链表管理生命周期，命中率低于95%说明不足，高于99.5%则可能冗余。
MySQL InnoDB缓冲池（Buffer Pool）不是“可选优化项”，而是InnoDB读写路径的必经主干道——没有它，每次查询或修改都得直连磁盘，性能会断崖式下跌。
Buffer Pool 是内存里的数据页中转站
InnoDB以16KB为单位从磁盘读写数据，这些单位叫“页”（Page）。Buffer Pool就是一块连续内存区域，专门用来暂存这些页：包括数据页、索引页、Undo页、插入缓存（Insert Buffer）页等。它不只缓存用户数据，还承载锁信息、自适应哈希索引（AHI）、双写缓冲（Doublewrite Buffer）等关键运行时结构。
所有读操作都先查Buffer Pool；所有写操作都先改Buffer Pool里的副本，再异步刷盘。换句话说，99%以上的热数据访问根本不碰磁盘。
它靠三张链表管理页的生命周期
Buffer Pool内部不用哈希表或数组随机存取，而是用三个双向链表协同调度：
-
Free List：空闲页队列，新加载页从这里分配 -
LRU List：按访问热度排序的使用中页，但不是纯LRU——它被中点（midpoint）切分为Young区（5/8）和Old区（3/8） -
Flush List：脏页（dirty page）队列，记录哪些页被修改过但还没落盘
当Free List耗尽，系统就从LRU List尾部淘汰页；若被淘汰页在Flush List里，必须先刷盘再释放——这个联动机制决定了缓冲池是否“稳得住”。
默认128MB太小，但盲目设大也有代价
MySQL 8.0+默认innodb_buffer_pool_size是128MB，对任何稍有流量的业务都不够用。生产环境常见配置是物理内存的60%–80%，但要注意：
- 设置超过可用物理内存，会触发OS级swap，反而让I/O更慢
- 单实例
Buffer Pool超过64GB时，建议开启innodb_buffer_pool_instances（如设为8），避免单链表锁争用 -
SET PERSIST可持久化修改，但调整后仍需观察Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads比值——命中率低于95%说明不够用，高于99.5%又可能冗余
它不是静态缓存，而是一套带策略的动态系统
很多人以为调大innodb_buffer_pool_size就万事大吉，其实真正影响效果的是背后策略：
- 预读（
innodb_read_ahead_threshold）会主动加载相邻页，但全表扫描时容易把热数据挤出——这正是innodb_old_blocks_pct（默认37%）和innodb_old_blocks_time（默认1000ms）要约束的 - 脏页刷新受
innodb_io_capacity限制，若SSD实际IOPS是3000，却只配200，会导致Flush List堆积、Free List枯竭、最终阻塞写入 -
Buffer Poolresize支持在线调整，但以chunk为单位（默认1MB），过程会短暂阻塞页面分配，不能在高峰期执行
真正难的不是“知道它存在”，而是理解它如何在读、写、淘汰、刷盘之间做实时权衡——一个参数微调，可能让冷查询变快，也可能让热更新卡住。
