性能下降主因是innodb_buffer_pool_size未随内存扩容调整，导致缓存命中率低于99%、磁盘随机读激增；需按Pod内存limit的70%设置该值，并合理配置instances、热加载及old_blocks_pct参数。
迁移后性能掉一半，八成卡在 innodb_buffer_pool_size 没调——新节点内存翻倍，但配置还沿用旧值，缓存池吃不下热数据，大量磁盘随机读直接拖垮 QPS。
查当前缓冲池配置和命中率是否拉胯
别猜，直接看真实指标。先确认 innodb_buffer_pool_size 是不是还在用老服务器的 512M 或 1G；再看实际有没有被“喂饱”：
- 执行
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';，对比新节点物理内存（比如 64G），若结果远小于 45G，基本就是根因 - 运行
SHOW ENGINE INNODB STATUS\G，搜Buffer pool hit rate，低于99%就危险——说明每 100 次读有超过 1 次要刷盘 - 注意：K8s 环境里 Pod 内存 limit 不等于宿主机内存，
innodb_buffer_pool_size必须 ≤ Pod memory limit × 0.7，否则 OOM killer 会干掉 mysqld
盯紧 innodb_buffer_pool_instances 别设多
StatefulSet 启动时 MySQL 自动按 CPU 核数推算该值，新 K8s 节点核数多，它可能设成 32，反而引发 mutex 争用、局部性变差：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 查当前值：
SHOW VARIABLES LIKE 'innodb_buffer_pool_instances'; - 经验上限：
innodb_buffer_pool_instances≤innodb_buffer_pool_size/ 1G（例如池子 50G，设 32 就过头，16 更稳） - 如果业务以大范围扫描为主（如定时报表），可试设为 4 或 8，同时监控
Innodb_buffer_pool_wait_free是否飙升——涨了就得加回
确认缓存热加载开关有没有开
Pod 重启后缓存全丢，前几分钟全是慢查询，这不是配置错，是“没继承”：
- 必须同时开启两个参数：
innodb_buffer_pool_dump_at_shutdown = ON和innodb_buffer_pool_load_at_startup = ON - dump 文件默认在 datadir 下叫
ib_buffer_pool，检查 Pod 内该路径权限是否可读写（Docker 挂载或 SELinux 常拦在这里） - 首次加载耗时长？用
innodb_buffer_pool_dump_pct = 75控制只 dump 最热 75% 页面，减少启动延迟
别漏掉 innodb_old_blocks_pct 这个隐形杀手
批量导入或 ETL 任务一跑，刚加载的页就被踢出，热点数据留不住：
- 默认
innodb_old_blocks_pct = 37，意味着 LRU 链前端 37% 区域专留给“老页”，新页只在后端插入 - 若观察到
Innodb_buffer_pool_reads暴增而Innodb_buffer_pool_read_requests变化不大，大概率是新页误杀老页 - 对写密集型负载，可尝试调高至
50；但调太高会降低冷数据淘汰效率，得结合SHOW ENGINE INNODB STATUS里的old blocks统计微调
真正麻烦的从来不是单个参数，而是 K8s 环境下这些值和宿主机资源、Pod limits、甚至 Longhorn 副本重建节奏之间的耦合——比如 buffer pool 设大了，但 PVC IO 延迟高，反而放大抖动。调参前务必先看 iostat -x 1 和 kubectl top pods 的实时反馈。
