mysql不支持百分比写法，必须填具体字节数或带单位的值（如48g）；需根据物理内存总量扣减os及其他进程开销后计算，再满足chunk对齐要求，并通过select @@innodb_buffer_pool_size验证是否生效。
直接填 innodb_buffer_pool_size = 70% 是无效的——MySQL 不支持百分比写法，必须填具体字节数或带单位的值（如 48G）。
怎么算出 70% 对应的具体数值
不能靠心算或拍脑袋。真实配置必须基于服务器当前可用物理内存，再扣掉操作系统和其他进程的刚性开销：
- 用
free -m或cat /proc/meminfo | grep MemTotal看清实际总内存（比如显示MemTotal: 131856532 kB≈ 125.7GB） - 专用数据库服务器：预留 1~2GB 给 OS，其余按 70% 计算 → 125.7 × 0.7 ≈ 88GB，再减去 2GB → 推荐设为
86G - 混合部署（如跑着 Nginx + PHP-FPM）：先用
ps aux --sort=-%mem | head -10看常驻大内存进程，再用free -m的available值做基准，取其 60%~70% 更安全 - 注意 chunk 对齐：MySQL 8.0+ 要求该值必须是
innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的整数倍，默认 chunk 是 128MB。若设了innodb_buffer_pool_instances = 8，最小步进就是 1024MB，填86G可能被自动向下对齐到85G（85 × 1024 = 87040 MB），要提前验证
配置方式选哪个：SET GLOBAL 还是改 my.cnf
两者都能生效，但行为差异极大：
-
SET GLOBAL innodb_buffer_pool_size = 86*1024*1024*1024：MySQL 5.7+ 支持在线调整，但仅限于“增大”且必须是 chunk 对齐后的值；缩小会报错，且重启后丢失 - 改
my.cnf（或mysqld.cnf）的[mysqld]段：innodb_buffer_pool_size = 86G：推荐长期使用，确保重启后仍生效；修改后必须重启 MySQL（systemctl restart mysql）才加载新值 - 别混用：如果已用
SET GLOBAL动态调大过，再改配置文件却不重启，会导致配置文件值和运行时值不一致，监控时容易误判
设完之后怎么确认它真按你的意图工作了
光写进配置不等于生效，更不等于高效。必须立刻验证三件事：
- 查是否加载成功：
SELECT @@innodb_buffer_pool_size / 1024 / 1024 / 1024;看返回是否接近你设的 GB 数（注意单位换算） - 查命中率是否健康：
SHOW ENGINE INNODB STATUS\G，搜Buffer pool hit rate，持续低于 95% 就说明还是太小，或者有大量全表扫描在污染缓存 - 查有无等待：
SHOW STATUS LIKE 'Innodb_buffer_pool_wait_free';，该值非 0 表示 Buffer Pool 太小、频繁刷脏页腾空间，得立刻调大 - 观察系统层面：
top或htop看mysqld进程 RES 内存是否接近你设的值，同时free -m的available是否仍 >1GB —— 如果 available 接近 0，说明 OS 开始 swap，必须降值
最常被忽略的一点：Buffer Pool 不是越大越好，而是要在“热数据装得下”和“OS 不被挤爆”之间找平衡点。很多人设完就以为万事大吉，结果几小时后发现系统卡死、OOM Killer 杀了 mysqld，回头一看 innodb_buffer_pool_size 占了 95% 内存——那不是优化，是自毁。
