innodb_buffer_pool_size必须按真实InnoDB数据量和内存余量精确计算，而非简单填百分比；查真实占用用SELECT CEILING(SUM(data_length + index_length) / 1024 / 1024) AS mb FROM information_schema.tables WHERE engine='InnoDB';，≤2GB设512M–1G，5–15GB按物理内存50%–75%设但上限≤30G，共存服务需先预留2–4GB；配置单位仅支持G/M/K，值须为chunk_size×instances整数倍，修改后必须重启并用SHOW VARIABLES验证。
innodb_buffer_pool_size 不是填个百分比就完事，设错会直接触发 OOM 或让磁盘 I/O 疯涨——必须按真实数据量 + 内存余量来算，不是拍脑袋。
怎么查当前 InnoDB 实际占用空间
别猜，直接从 information_schema 里捞真实数据大小：
SELECT CEILING(SUM(data_length + index_length) / 1024 / 1024) AS mb FROM information_schema.tables WHERE engine='InnoDB';
这个结果才是你缓存池的「底线」：如果总数据才 800MB，设 4G 就纯属浪费；设 512MB 可能刚够，但留点余量更稳。
- 结果 ≤ 2GB → 建议
innodb_buffer_pool_size = 512M～1G - 结果在 5–15GB → 按物理内存的 50%–75% 算，但上限别超
30G（大页分配容易失败） - 和 Nginx/PHP 共存 → 先扣掉 2–4GB 给 OS 和其他进程，再分剩余内存
配置文件里怎么写才生效
改 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf 的 [mysqld] 段，注意单位和格式：
- 只支持
G/M/K，不能写GB或MB（innodb_buffer_pool_size = 8G✅，= 8GB❌） - 值必须是
innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的整数倍，默认 chunk 是 128M，instance 默认是 8 → 最小调整粒度是1024M（即 1G） - 改完必须重启：
systemctl restart mysql，SET GLOBAL在 MySQL 5.7+ 虽支持动态调，但仅限增减 chunk 数量，主大小仍要重启
重启后立刻验证：SHOW VARIABLES LIKE 'innodb_buffer_pool_size';，别信配置文件写了就等于生效。
设太大或太小的典型症状
不是 CPU 高才叫性能差——很多卡顿其实是缓存池没配对：
- 启动失败报
Cannot allocate memory→ 设太大，OS 拒绝分配 -
SHOW ENGINE INNODB STATUS里Buffer pool hit rate长期 - 监控看到
innodb_data_reads暴增、CPU 却不高 → 磁盘 I/O 成瓶颈，不是 SQL 问题 -
innodb_buffer_pool_wait_free非零 → 缓存池太大，后台刷脏页压力重，反而拖慢写入
MySQL 5.7+ 动态调整的坑
虽然支持 SET GLOBAL innodb_buffer_pool_size = ...，但实际用起来限制多：
- 必须有
SYSTEM_VARIABLES_ADMIN权限（GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'user'@'%'） - 新值必须是
innodb_buffer_pool_chunk_size的整数倍，否则会被自动 round down - 调整过程异步进行，查
SHOW STATUS LIKE 'innodb_buffer_pool_resize_status';看进度，期间可能短暂影响并发性能 - 动态改的值在重启后丢失，生产环境别依赖它做长期配置
真正上线前的调优，永远优先走配置文件 + 重启这条路。动态调整只适合临时压测或紧急救火，且得盯住 resize 状态。
