InnoDB缓冲池大小应基于实际工作集而非固定比例，通过命中率、页使用率和wait_free指标动态调整；实例数需匹配总大小以避免争用；预热需dump与load参数配合且依赖SQL效率。
innodb_buffer_pool_size 设置多大才合理
这个值决定 InnoDB 能缓存多少数据和索引，设得太小会导致频繁磁盘读，太大则可能挤占系统内存引发 swap。关键不是看“推荐 70%~80%”，而是看实际工作集大小。
- 先查当前缓冲池命中率：
SHOW STATUS LIKE 'Innodb_buffer_pool_reads';和SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests';，用前者除以后者，低于 99.5% 就值得调 - 观察
Innodb_buffer_pool_pages_total和Innodb_buffer_pool_pages_data，如果后者长期接近前者，说明几乎全被占满，但还要结合Innodb_buffer_pool_wait_free是否非零——为零才说明没因淘汰页而阻塞 - 线上建议从
innodb_buffer_pool_size = 50% * 物理内存起步，再根据free -h中的可用内存余量逐步加，避免触发 OOM killer
要不要开 innodb_buffer_pool_instances
它把缓冲池拆成多个实例，减少并发访问时的 mutex 争用。但不是越多越好，开太多反而增加管理开销。
- MySQL 5.6+ 默认是 8，但仅当
innodb_buffer_pool_size > 1G时才建议启用；小于 1G 保持为 1 即可 - 每个 instance 最小约 1GB，所以若总大小是 12GB，设成 8 或 12 都可以，但不要设成 16（否则单个 instance 不足 1GB）
- 验证是否生效：查
SHOW VARIABLES LIKE 'innodb_buffer_pool_instances';，再看SHOW ENGINE INNODB STATUS\G中 “BUFFER POOL AND MEMORY” 段是否列出多个 instance
为什么开了 innodb_buffer_pool_dump_at_shutdown 还没效果
这个参数只是让 MySQL 在关闭前把热页列表写到磁盘，但重启后要真正加载，还得配对开启 innodb_buffer_pool_load_at_startup。
- 必须同时设置两个参数才构成完整流程：
innodb_buffer_pool_dump_at_shutdown=ON+innodb_buffer_pool_load_at_startup=ON - dump 文件默认在数据目录下叫
ib_buffer_pool，路径可通过innodb_buffer_pool_filename修改 - 注意 dump 是异步执行的，关库时不会等它完成；如果关库太快，文件可能为空或不全，此时重启加载也无效
- 可手动触发 dump：
SELECT * FROM sys.schema_table_statistics WHERE table_name = 'innodb_buffer_pool_dump_status';（MySQL 8.0+），或直接执行SET GLOBAL innodb_buffer_pool_dump_now = ON;
缓冲池预热后性能还是上不去？检查这几个点
预热只解决“冷启动抖动”，不代表整体性能瓶颈消失。很多问题藏在缓冲池之外。
-
innodb_log_file_size太小会导致频繁 checkpoint，拖慢写入——建议单个 log file ≥ 1GB，且总大小 ≈ 1~2 小时的写入量 - 表没有主键或主键过长，会让二级索引回表代价变高，即使数据在 buffer pool 里，逻辑读也多
- 查询用了
SELECT *或大字段（如TEXT、BLOB），这些列默认不进 buffer pool（除非innodb_large_prefix=ON且行格式支持），导致反复读磁盘 - 监控
Innodb_buffer_pool_read_ahead是否异常高——可能是全表扫描或范围查询没走对索引，预热救不了低效 SQL
缓冲池调优最易被忽略的是：它只管“能不能缓存”，不管“该不该缓存”。业务访问模式一变，昨天最优的配置今天就可能成为瓶颈。务必结合 slow log 和 performance_schema 的语句级统计来看真实热点。
