核心问题是innodb_buffer_pool_size过大或binlog未关闭；需根据available内存设合理buffer pool（如4G机设1G）、添加skip-log-bin关闭binlog，并删旧ib_logfile与binlog文件后重启验证。
MySQL 8.0 在宝塔面板里内存飙升、频繁被 OOM killer 杀掉，核心问题往往就两个：innodb_buffer_pool_size 设得太大，或 binlog 没关导致日志堆积+额外内存开销。不是所有高内存占用都该调优，先确认是不是这两个真凶。
查清 MySQL 实际用了多少内存
别只看 top 里 mysqld 进程的 RES 值——那包含大量可回收缓存，误导性很强。真正要盯的是 InnoDB 缓冲池实际分配量和系统可用内存余量：
- 执行
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"，确认当前值（单位是字节，用awk '{printf "%.2fG\n", $1/1024/1024/1024}'换算） - 运行
free -h，重点看available列，不是free；如果available小于innodb_buffer_pool_size，基本就是它把系统逼到墙角了 - 检查是否启用了 binlog：
mysql -e "SHOW VARIABLES LIKE 'log_bin';"，返回ON就说明开着
调低 innodb_buffer_pool_size 要满足三个硬性条件
直接改 my.cnf 里的 innodb_buffer_pool_size 不一定生效，MySQL 8.0 对这个参数有严格校验：
- 必须是
innodb_buffer_pool_chunk_size×innodb_buffer_pool_instances的整数倍（默认 chunk 是 128M，instances 是 8 → 最小合法值是 1G） - 如果原值是 2G，想降到 1.5G，MySQL 启动会报错
Invalid value for innodb_buffer_pool_size，必须同步调整 instances 或 chunk - 改完后必须删掉旧的
ib_logfile0和ib_logfile1（路径通常是/www/server/data/），否则启动卡在InnoDB: Error: log file ib_logfile0 is of different size - 推荐安全起点：2GB 内存服务器设为
512M，4GB 设为1G，8GB 以上再考虑 2G–4G，并始终留出 ≥2GB 给系统和其他进程
关闭 binlog 能省下可观内存和磁盘 I/O
除非你在做主从复制或需要闪回恢复，否则宝塔单机环境开 binlog 纯属负担。它不光占磁盘，还会让每个事务多一次写入缓冲、多一次 fsync，间接推高内存压力：
- 编辑
/www/server/mysql/etc/my.cnf，在[mysqld]段下添加一行：skip-log-bin（注意不是log_bin=OFF，后者无效） - 删掉已有的 binlog 文件：
rm -f /www/server/data/mysql-bin.* - 重启 MySQL：
service mysqld restart，再查SHOW VARIABLES LIKE 'log_bin';应返回OFF - 顺手关掉无关插件释放资源：
skip-audit-plugin、skip-performance-schema（若不用性能分析）
改完配置后必须验证是否真正生效
宝塔有时会读取多个配置文件，或者你改错了段落位置，导致修改被忽略：
- 运行
mysqld --verbose --help | grep "Default options"，确认 MySQL 实际加载的是哪个my.cnf路径 - 检查配置文件开头是否有
[mysqld]，所有你要调的参数必须严格落在这一段下面，不能悬空或混在[client]里 - 重启后立刻执行
mysql -e "SELECT @@innodb_buffer_pool_size, @@log_bin;"，双参数一起查，避免只看一个误判 - 观察 10 分钟内
free -h的available是否稳定回升，且不再触发dmesg | grep -i "killed process"里的 mysqld 记录
最容易被忽略的是：Buffer Pool 大小变更后，InnoDB 必须重建日志文件，而这个过程会临时吃掉更多内存。所以删 ib_logfile* 和重启之间不能跳步，也不能指望“改完就立刻降内存”。
