MySQL频繁OOM被系统KILL，需先用dmesg确认是否内核触发OOM Killer杀进程；再合理设置innodb_buffer_pool_size（4GB服务器建议≤2.2G），禁用buffer_pool_dump/load，手动编辑my.cnf并验证生效。
MySQL频繁OOM被系统KILL，先查oom_kill日志确认是不是真内存不足
宝塔面板里MySQL隔几小时挂一次，页面报“连接被拒绝”或mysqladmin ping失败，不代表一定是MySQL自己崩了——很可能是Linux内核触发OOM Killer把mysqld进程干掉了。先SSH进服务器执行：
sudo dmesg -T | grep -i "killed process" | grep mysqld如果输出类似
Killed process 12345 (mysqld) total-vm:2048764kB, anon-rss:1892340kB，说明是内存超限被强杀，不是MySQL内部错误。这时候调innodb_buffer_pool_size只是治标，必须同步限制MySQL总内存上限。
innodb_buffer_pool_size不能只看物理内存的70%，得扣掉系统和其他服务开销
很多教程说“设成物理内存的50%–75%”，但在宝塔环境下极易翻车。宝塔本身（bt守护进程、Nginx、PHP-FPM）常驻吃掉1–2GB，还要留至少512MB给系统缓存和突发负载。假设你买的是4GB内存的轻量服务器：
- 别设
innodb_buffer_pool_size = 3G，实际能安全用的顶多2.2G - 在
/www/server/mysql/etc/my.cnf的[mysqld]段下明确写死，别用百分比（MySQL 5.7+不支持动态百分比配置） - 改完必须重启MySQL：
service mysqld restart，systemctl restart mysqld在宝塔里可能不生效 - 验证是否生效：
mysql -uroot -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"，返回值单位是字节，除以1024²看GB是否匹配
光调缓存池不够，还得关掉innodb_buffer_pool_dump_at_shutdown这类隐形内存大户
MySQL 5.7默认开启innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup，目的是加速重启后热数据加载。但宝塔用户多数是小站+低频重启，这俩功能反而在MySQL关闭瞬间把整个Buffer Pool dump到磁盘（生成ib_buffer_pool文件），启动时又全读进内存——造成启动卡顿、内存尖峰，甚至触发OOM。直接禁用：
innodb_buffer_pool_dump_at_shutdown = OFF<br>innodb_buffer_pool_load_at_startup = OFF顺手加上
innodb_log_file_size = 256M（默认48M太小，写入密集时日志频繁刷盘拖慢性能），改完记得删掉旧日志文件：rm /www/server/mysql/data/ib_logfile*，再重启MySQL（它会自动重建）。
宝塔后台“数据库配置”页改的参数根本不会写入my.cnf，必须手动编辑
宝塔面板右上角“数据库 → 设置 → 配置修改”，看着能调buffer_pool_size，但实际只是改了个前端显示值，底层my.cnf文件完全不动。你点“保存”后去查my.cnf，里面还是空的或者只有注释。所有关键参数必须SSH进去手动改：vi /www/server/mysql/etc/my.cnf，在[mysqld]块里加行，注意别加到[client]或[mysql]块里。改完检查语法：/www/server/mysql/bin/mysqld --defaults-file=/www/server/mysql/etc/my.cnf --validate-config，返回2024-01-01T00:00:00Z mysqld: ready for connections.才算通过。
真正卡住人的地方往往不是参数值本身，而是宝塔把MySQL当黑盒封装后，用户误以为界面上的操作等于生效。内存类调优尤其敏感，差256MB就可能从稳定变成每小时KILL一次——务必用dmesg验死因，用SHOW VARIABLES验结果，用ps aux --sort=-%mem | head盯实时内存占用。
