新环境InnoDB缓冲池配置错误是MySQL迁移后性能骤降的主因：buffer_pool_size未随内存扩容调整、instances过多加剧争用、未启用启停缓存加载、LRU策略未适配业务热点。
为什么新环境的innodb_buffer_pool_size几乎总是错的
MySQL迁移后性能掉一半，八成卡在这儿：新服务器内存更大，但innodb_buffer_pool_size还沿用旧配置，比如死守128M或512M。InnoDB缓存池不是“设了就行”，它得吃下热数据+索引，否则大量磁盘随机读直接拖垮QPS。
- 查当前值：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; - 看实际使用率：
SHOW ENGINE INNODB STATUS\G里找Buffer pool hit rate，低于99%就危险 - 推荐初始值：专用DB服务器上设为物理内存的
70%~80%（例如 64G 内存 →50G），但必须留够系统和其他进程空间 - 注意：该参数在 MySQL 5.7+ 支持动态调整（
SET GLOBAL innodb_buffer_pool_size = 53687091200;），但仅限整数倍的128MB粒度，设50G可能被自动对齐到50.06G
迁移后innodb_buffer_pool_instances变多反而更慢
新服务器CPU核数翻倍，MySQL自动把innodb_buffer_pool_instances从8拉到16甚至32，结果锁竞争加剧、缓存局部性变差——尤其当单表热点高或查询模式集中时。
- 该参数本质是把缓冲池切片分给不同线程，减少
mutex争用；但切太碎会导致每个实例命中率下降，冷数据挤热数据 - 经验法则：保持
innodb_buffer_pool_instances≤innodb_buffer_pool_size / 1G（例如50G池子，设32就过头了，16更稳） - 若业务以大范围扫描为主（如报表），可尝试调低到
4或8，观察Innodb_buffer_pool_wait_free是否上升
innodb_buffer_pool_dump_at_shutdown没开，重启后缓存全丢
老环境可能没启用热加载，迁移后又忘了配，结果每次服务重启，缓存池空载运行数小时，慢查询暴增——这不是配置错了，是“没继承”。
- 必须同时开启两个开关：
innodb_buffer_pool_dump_at_shutdown = ON和innodb_buffer_pool_load_at_startup = ON - dump文件默认在
datadir下叫ib_buffer_pool，确认权限可读写（常见坑：SELinux 或 Docker 挂载限制） - 首次启动加载耗时取决于dump文件大小，可通过
innodb_buffer_pool_dump_pct控制只 dump 热点页（如设75，只存最热75%）
别忽略innodb_old_blocks_pct和innodb_old_blocks_time
有些迁移后的慢查询集中在“刚加载进缓存就被踢出”，尤其是批量导入或ETL任务——这是LRU链被干扰，新页误杀老热点页。
-
innodb_old_blocks_pct默认37（即37%区域留给“老”页），若业务有稳定热点，可提到50；但太高会降低新页预热效率 -
innodb_old_blocks_time控制新页升为“老页”的冷却时间（单位毫秒），默认0，意味着一加载就可能被扫走；设1000可让新页至少驻留1秒再参与淘汰 - 验证效果：对比
SHOW STATUS LIKE 'Innodb_buffer_pool_reads'和Innodb_buffer_pool_read_requests，比值应明显下降
真正卡住性能的，往往不是参数本身多难调，而是迁移时复制了my.cnf却漏掉了缓冲池相关的上下文依赖——比如旧服务器用SSD所以敢小池子，新环境换成了NVMe但还按HDD逻辑配；或者开发库跑得好，上线前没压测真实缓存压力。这些细节不盯住，光改一个innodb_buffer_pool_size没用。
