MySQL升级后锁竞争飙升，主因是innodb_buffer_pool_instances默认值从5.7的8降为8.0的1，导致所有线程争抢同一buffer pool mutex；验证需查变量值、INNODB STATUS中实例明细及spin_waits指标。
MySQL 升级后出现锁槽竞争，大概率不是 innodb_buffer_pool_instances 调高了，而是它被悄悄设回了 1 —— 尤其是从 5.7 升到 8.0 时，默认值从 8 变成 1，所有线程立刻挤回同一把 buf_pool_mutex。
为什么升级后突然锁竞争飙升？
MySQL 5.7 默认 innodb_buffer_pool_instances = 8（当 innodb_buffer_pool_size ≥ 1GB），而 8.0 默认降为 1。升级不改配置的话，哪怕你原来 buffer pool 是 16GB，也会退化成单实例单锁。现象是：SHOW ENGINE INNODB STATUS\G 的 SEMAPHORES 段里频繁看到 RW-latch created in file buf0buf.cc，Innodb_buffer_pool_mutex_spin_waits 暴涨，但 Buffer pool hit rate 看着还行——这是典型“请求排队等锁”，不是真缺缓存。
怎么确认是不是 instances 回退导致的？
别只查变量值，要验证运行时状态：
- 执行
SHOW VARIABLES LIKE 'innodb_buffer_pool_instances';—— 看是否真为 1 - 执行
SHOW ENGINE INNODB STATUS\G，搜BUFFER POOL AND MEMORY段，确认是否只显示Buffer pool size 16384（无分实例明细）；若看到Instance 0、Instance 1等多行，说明已生效 - 监控
Innodb_buffer_pool_wait_free：持续 > 0 表示刷脏压力大或实例数太少，但若该值低而spin_waits高，基本锁定是单实例锁争用
设多少才真正起作用？
不能只看 CPU 核数或拍脑袋填 8：
- 先算硬约束：
innodb_buffer_pool_size必须能被innodb_buffer_pool_instances整除，且每个实例 ≥ 1GB（即size ÷ instances ≥ 1024M） - 再看 chunk 对齐：MySQL 5.7+ 使用
innodb_buffer_pool_chunk_size（默认 128MB）管理内存块，实际生效大小 =chunk_size × instances × N；若设size = 1500M且instances = 8，最小粒度是 1024MB，MySQL 会自动向上取整到 2048MB，可能触发 OOM - 推荐组合（基于当前总 buffer pool 大小）：
– ≤ 8GB → 设 4 或 8
– 8–24GB → 设 8 或 16
– ≥ 24GB 且 CPU ≥ 16 核 → 可试 16，但不超过 64
改完必须重启，且要注意启动失败风险
innodb_buffer_pool_instances 是只读参数，SET 不生效，必须写进配置文件并重启 mysqld。但重启前务必检查：
- 配置文件中
innodb_buffer_pool_size和innodb_buffer_pool_instances是否满足整除关系，否则 MySQL 启动时会静默向下取整（比如设 12GB / 5 实例 → 实际按 10GB 加载），导致可用内存缩水 - 容器或低内存环境要特别小心：若物理内存仅 4GB，设
innodb_buffer_pool_size = 3G+instances = 8，每个实例仅 375MB，远低于 1GB 下限，反而加剧页淘汰和锁开销 - 多路 NUMA 服务器上，建议用
numactl --interleave=all mysqld启动，避免某些实例始终访问远端内存节点
最常被忽略的一点：调高 innodb_buffer_pool_instances 只解决缓冲池层面的锁竞争，如果业务 SQL 还在扫全表、加间隙锁、或事务持有时间过长，innodb_row_lock_waits 和 innodb_lock_structs 依然会高——得一起看，别把锁问题全归给 buffer pool。
