是OOM Killer干的，需先执行free -h看available是否长期低于200M，再用dmesg -T | grep -i "killed process"确认是否有mysqld被杀记录；OVZ架构不支持Swap，KVM/XEN建议用宝塔工具箱一键配置；同时必须下调innodb_buffer_pool_size至物理内存50%、限制max_connections及单连接缓冲参数。
MySQL频繁重启是不是OOM Killer干的？
先确认是不是内存真不够，而不是面板误报。进宝塔终端执行 free -h，重点看 available 列——如果长期低于 200M，基本就是物理内存见底了；再跑 dmesg -T | grep -i "killed process"，如果输出里有 mysqld，说明内核已经动手杀进程了。
常见误判点：used 高≠内存不足（Linux会把空闲内存当缓存用），Swap: 0B 也不代表没文件，可能只是被 swapoff 关了。OVZ架构的VPS不支持Swap，强行操作会失败，这点必须提前确认。
用宝塔工具箱一键启用Swap最稳妥
KVM/XEN架构（阿里云、腾讯云等主流厂商）直接走图形化路径，避免命令输错或权限问题：
- 宝塔【软件商店】→ 搜索安装【Linux工具箱】
- 安装后点【设置】→ 左侧选【Swap/虚拟内存】
- 填大小：1GB内存配2G Swap，2GB配2G，4GB配1–2G，≥8GB可不设
- 点【确定】，后台自动完成
fallocate、mkswap、swapon和写入/etc/fstab
完成后立刻执行 free -h，Swap 行应显示对应大小且 used 为 0 —— 这表示已就位但尚未触发，是正常状态。
在my.cnf里砍掉MySQL内存大户参数
宝塔默认给 innodb_buffer_pool_size 分配物理内存的50%～70%，但PHP、Nginx、Redis一起跑，这个值很容易踩线。进【软件商店】→ MySQL → 【设置】→ 【配置修改】，在 [mysqld] 段落做以下调整：
-
innodb_buffer_pool_size = 1024M（2GB内存机器，别超50%） -
max_connections = 80（小站够用，别留150+空连接吃内存） -
tmp_table_size = 64M和max_heap_table_size = 64M（限制内存临时表上限） -
sort_buffer_size = 256K、join_buffer_size = 256K（单连接不许乱开大缓冲）
改完点【保存】，再点【重启MySQL】。别跳过重启——配置不生效等于白调。
为什么只加Swap还不够？
Swap只是“延缓死亡”，不是根治方案。它会让MySQL在内存紧张时把冷数据换出到磁盘，但一旦磁盘I/O跟不上（比如用机械硬盘或低配云盘），await 拉高、%util 长期＞90%，MySQL刷脏页或写binlog就会卡死超时，最终还是自我退出。这时候错误日志里会出现 InnoDB: Error: Write to file ./ibdata1 failed 这类提示。
所以必须同步压低并发和单连接资源——否则Swap只是把OOM从秒级拖成分钟级，反而让问题更难定位。
