这类问题我又碰上了一次。MySQL 8.0.32，把 innodb_buffer_pool_size 从 128M 改成 8G，写进 my.cnf 后重启，SHOW VARIABLES 里还是 134217728，free -m 也看不出占用了 8G。
第一反应是「写成 8GB 这种带单位的字符串，8.0 只认 M 或 G 后缀」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。参数写在了 client 段里，mysqld 根本不读这一段；另有 conf.d 目录下的配置覆盖了 my.cnf；容器里内存限制是 4G，buffer pool 被自动收缩到限制以内。
先确认到底是哪份配置在生效
mysqld --verbose --help | grep -A1 'Default options'接着查看运行时值和配置文件里的写法
mysql -e 'SHOW VARIABLES' | grep buffer_pool_size; grep -rn innodb_buffer_pool_size /etc/mysql/然后改成规范写法并只留一处
sed -i 's/^innodb_buffer_pool_size.*/innodb_buffer_pool_size = 8G/' /etc/mysql/mysql.conf.d/mysqld.cnf末了重启后确认值真的变了
systemctl restart mysql && mysql -e 'SHOW VARIABLES' | grep buffer_pool_size隔了一天再看，现象没变，说明不是偶发。
那几天正好在做别的变更，先把时间线对齐才敢动手。
怎么算真的好了，看的是同一批现象。SHOW VARIABLES 返回 8589934592，热数据查询的磁盘读明显减少，Innodb_buffer_pool_reads 增速降下来。
容易忽略的是，缓冲池改大后要观察 swap，机器内存不足时反而更慢；从 128M 直接跳到 8G 记得留出系统和其他进程的空间。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。