先关闭innodb_dedicated_server，再依据命中率（持续低于99%需警惕）和空闲页占比（长期＞25%说明设大了）判断buffer pool是否合理，否则手动配置可能被覆盖或失效。
直接结论：别凭物理内存百分比硬套，先看 innodb_dedicated_server 是否开着，再查当前命中率和空闲页比例——否则调得再“合理”，也可能白忙。
为什么一上来就要关掉 innodb_dedicated_server
MySQL 8.0 默认开启 innodb_dedicated_server=ON，它会根据总内存自动设 innodb_buffer_pool_size，但策略只认“服务器专用于 MySQL”这一种场景。现实中混部（比如同时跑 Nginx、Java 应用）极常见，它却不管其他进程，常把 buffer pool 设得过大，挤占 OS 内存，引发 swap 或 OOM。
- 查当前状态：
SHOW VARIABLES LIKE 'innodb_dedicated_server';，若返回ON，立刻在my.cnf的[mysqld]下加一行：innodb_dedicated_server = OFF - 改完必须重启 MySQL，动态 SET 不生效
- 关掉后，你才真正拿到控制权；否则所有手动配置都可能被启动时覆盖或干扰
怎么判断当前值够不够用？只看命中率不够
光看 SHOW ENGINE INNODB STATUS\G 里的 Buffer pool hit rate 容易误判——它反映的是“最近几秒”的热度，而真实瓶颈常藏在长期空闲页堆积或突发读放大里。
- 查命中率（基础）：
SELECT (1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)) * 100 AS hit_rate FROM performance_schema.global_status WHERE variable_name IN ('Innodb_buffer_pool_reads', 'Innodb_buffer_pool_read_requests');—— 持续低于99.0就该警惕 - 查空闲页占比（更关键）：
SELECT (Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total) * 100 AS free_pct FROM performance_schema.global_status WHERE variable_name IN ('Innodb_buffer_pool_pages_free', 'Innodb_buffer_pool_pages_total');—— 若长期 >25%，说明设大了；若且命中率又低，大概率真不够 - 注意：这两个指标要结合看，单看一个容易走偏
设置值不是拍脑袋定的，得满足 chunk 对齐规则
innodb_buffer_pool_size 不是随便写个数字就行。它必须是 innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances 的整数倍，默认 chunk 是 128M，默认 instances 是 1，所以默认最小合法步进就是 128M。设错会导致 MySQL 启动失败，或自动向下取整（比如你写 10G，实际变成 9.875G），悄无声息地浪费内存。
- 查当前配置：
SHOW VARIABLES LIKE 'innodb_buffer_pool%'; - 推荐做法：先固定
innodb_buffer_pool_instances（比如 8 或 16），再算出 chunk 基准值；例如设instances = 8，则每 chunk 是128M × 8 = 1024M，那么 buffer pool 应设为1024M、2048M、4096M这样的整数倍 - 设完重启后，用
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';确认是否被修正过——被修正是危险信号
最终值怎么定？从系统可用内存倒推，留足余量
所谓“平衡”，本质是让 MySQL 用得爽，OS 和其他进程也不卡。不能只盯着数据库性能，忽略整个系统的稳定性。
- 先用
free -m看真实可用内存，减去：OS 至少预留1.5G、其他关键进程（如 JVM 堆、Nginx worker）已知占用、临时文件/swap 缓冲等 - 剩余内存的
60%~75%可作为 buffer pool 上限（专用库可到80%，混部建议压到65%封顶） - 举例：一台
32G内存的混部服务器，Nginx + Java 占约6G，OS 预留2G，剩24G；取65%得15.6G，再向下对齐到最近的1024M倍数 →15G（即15360M） - 这个值不是终点，上线后需持续观察
free_pct和hit_rate一周，再微调
最常被忽略的一点：buffer pool 实际 RSS 占用 ≈ 设置值 × 1.1（InnoDB 额外管理开销）。你以为设了 16G 就只吃 16G，其实系统看到的是接近 17.6G——这点余量，必须提前算进去。
