Buffer Pool大小应设为物理内存的60%–75%，并预留2–4GB给OS及其他进程；必须是128MB整数倍，命中率低于95%需调大，但须同步优化innodb_buffer_pool_instances和innodb_old_blocks_time等参数以避免锁争用或热数据污染。
Buffer Pool 大小设多少才不浪费也不缺？
物理内存的 60%–75% 是安全起点，但必须留出至少 2–4GB 给 OS、其他进程（如 Redis、应用服务）和 MySQL 自身线程栈。设太大容易触发 swap，反而拖慢 IO。
-
innodb_buffer_pool_size必须是innodb_buffer_pool_chunk_size（默认 128MB）的整数倍，否则启动时会自动向下取整——比如你设 48.5G，实际生效可能只有 48G - 线上调大建议分步：先设为当前值的 1.2 倍，观察 24 小时内
innodb_buffer_pool_reads是否明显下降，再决定是否继续加 - 用
SHOW ENGINE INNODB STATUS\G查看Buffer pool hit rate，低于 95% 就该警惕；但别只盯这个数字——如果innodb_buffer_pool_read_requests每秒才几百次，99% 也没意义
为什么开了多个实例反而性能更差？
多实例本质是把 Buffer Pool 拆成多个独立 LRU 链，减少并发访问时的 mutex 竞争。但拆得太碎，每个实例不到 1GB，会导致预读失效、冷热数据隔离失衡，甚至 chunk 分配失败。
-
innodb_buffer_pool_instances推荐值 =ceil(innodb_buffer_pool_size / 1G)，上限 16；64GB 缓冲池设 8 实例（每实例 8GB），比设 16（每实例 4GB）更稳 - MySQL 8.0+ 支持在线调整该参数，但仅限于增大——减小需重启，且不能低于当前实例数
- 检查是否真有锁争用：执行
SELECT * FROM performance_schema.events_waits_summary_global_by_event_name WHERE event_name LIKE 'wait/synch/mutex/innodb/buf_pool%'，若SUM_TIMER_WAIT明显高于其他 mutex，才说明需要增加实例数
全表扫描后热数据被挤出去了怎么办？
这是 Buffer Pool 的经典污染问题。InnoDB 的改进型 LRU 把链表分为 Young 和 Old 区，默认 Old 区页面只要 1 秒没被访问就会被淘汰，但全表扫描会把大量页面“刷”进 Old 区，瞬间清空热数据空间。
- 调大
innodb_old_blocks_time（单位 ms）是最直接手段，从默认 1000 提到 3000–5000，让扫描页在 Old 区多“躺”几秒，等真正有业务访问时才晋升 Young 区 - 配合降低
innodb_old_blocks_pct（默认 37），比如设为 25，缩小 Old 区占比，给 Young 区更多空间保热数据 - 注意：这两个参数调得过激（如
innodb_old_blocks_time=10000）会导致真实冷数据长期滞留，占用内存——得靠监控innodb_buffer_pool_pages_old和innodb_buffer_pool_pages_young比例来验证
重启后 Buffer Pool 还是冷的？怎么预热？
MySQL 默认重启后 Buffer Pool 是空的，首波请求全走磁盘。虽然 innodb_buffer_pool_load_at_startup=ON 能加载上次 dump 的快照，但快照只包含“当时存活”的页，不保证业务最热的那些表还在里面。
- 启用持久化：确保
innodb_buffer_pool_dump_at_shutdown=ON+innodb_buffer_pool_load_at_startup=ON，并确认 dump 文件路径（innodb_buffer_pool_filename）所在磁盘有足够空间 - 主动预热：在低峰期执行类似
SELECT /*+ NO_CACHE */ * FROM orders WHERE create_time > DATE_SUB(NOW(), INTERVAL 7 DAY)的查询，强制加载核心表热数据；注意加SQL_NO_CACHE或 MySQL 8.0+ 的/*+ NO_CACHE */hint，避免干扰 Query Cache（若启用） - 更稳妥的做法是结合 pt-archiver 或自定义脚本，按索引顺序扫描主键，比全表扫更友好——因为主键聚簇索引的物理顺序接近逻辑顺序，预读效率更高
缓冲池调优不是设完几个参数就一劳永逸的事。真正关键的是理解每个参数背后的数据流向：页面怎么进、怎么留、怎么淘汰。尤其要注意 innodb_buffer_pool_reads 和 innodb_buffer_pool_read_requests 这两个指标的比值变化趋势，而不是某次快照值。很多线上事故，都始于一次看似合理的 buffer pool 扩容，却忽略了实例数或 old time 的配套调整。
