合理，但需满足服务器专用于mysql、预留2–4gb系统内存、正确配置innodb_buffer_pool_instances等前提；超75%易触发oom或swap，影响稳定性。
innodb_buffer_pool_size 设为物理内存 75% 合理吗？
在大多数 OLTP 生产场景下，设为物理内存的 75% 是一个经验性安全上限，不是固定公式，更不是“越高越好”。它成立的前提是：机器专用于 MySQL、无其他内存密集型服务、系统预留内存足够（至少 2–4 GB）、且 innodb_buffer_pool_instances 配置得当。
常见错误现象包括：OOM killed mysqld、系统频繁 swap、show engine innodb status 中出现大量 Buffer pool hit rate 波动或低于 990/1000。这些往往不是因为值设低了，而是没留够系统余量或没调好实例数。
- 物理内存 64 GB → 建议
innodb_buffer_pool_size = 48G，而非 49G 或 50G - 必须同步设置
innodb_buffer_pool_instances = 8（≥ 1GB/instance），否则单实例锁争用会抵消内存增益 - 若机器还跑 Redis、Zabbix Agent 或备份脚本，这个比例要往下压到 60–65%
为什么不是 80% 或 90%？
Linux 内核、glibc 缓存、MySQL 自身线程栈、临时表、排序缓冲区（sort_buffer_size）、join 缓冲区（join_buffer_size）等都吃内存，且不计入 innodb_buffer_pool_size。一旦物理内存被耗尽，内核会触发 OOM Killer，而 mysqld 几乎总是第一个被杀的进程。
实测中，当 innodb_buffer_pool_size 占比超 75% 且并发连接 > 200 时，/proc/meminfo 中的 MemAvailable 常跌破 1.5 GB，此时即使 buffer pool hit rate 达 995，系统响应也会明显卡顿。
- 75% 是给内核页缓存、socket buffer、未预分配的 InnoDB 日志内存等留出缓冲空间
- MySQL 8.0+ 的
innodb_dedicated_server默认启用后会自动设为 75%，但仅适用于全新部署且无其他负载的服务器 - 不要依赖
free -h的 “available” 数值做决策——它不含 MySQL 已分配但未实际使用的内存页
如何验证当前设置是否合理？
看真实压力下的内存分布，而不是配置文件里的数字。关键指标不在 MySQL 内部状态，而在 OS 层和 InnoDB 底层反馈。
- 每小时执行一次：
mysqladmin ext -i10 | grep -E "Innodb_buffer_pool_pages_|Threads_connected"，观察 pages_free 是否长期 - 检查
/proc/meminfo中MemAvailable是否稳定 > 2 GB；若持续 - 运行
show global status like 'Innodb_buffer_pool_wait_free'，非零值说明 buffer pool 扩容/刷脏跟不上请求节奏 - 避免只看
Innodb_buffer_pool_hit_rate——它掩盖了冷热数据混杂导致的无效加载
SSD 服务器能设更高吗？
不能。SSD 改善的是磁盘 I/O 延迟，不是内存需求逻辑。buffer pool 的核心作用是减少对存储层的访问次数，而 SSD 再快也比内存慢两个数量级（μs vs ns）。把 buffer pool 从 75% 拉到 85%，带来的性能提升微乎其微，但 OOM 风险陡增。
真正该配合 SSD 调整的是 innodb_io_capacity 和 innodb_io_capacity_max，它们控制刷脏速度，与 buffer pool 大小无关。
- NVMe 服务器仍建议保持 75%，可适当提高
innodb_io_capacity = 2000（默认 200） - 如果业务有大量全表扫描，应优化 SQL 或加覆盖索引，而不是靠扩大 buffer pool 硬扛
- buffer pool 不会缓存 undo log、change buffer（除非已 merge）、redo log —— 这些内存开销必须单独估算
innodb_buffer_pool_instances 和系统层 vm.swappiness。前者设太小会导致 mutex 竞争，后者设太高会让内核过早 swap，两者都会让 75% 这个数字失效。 
