mysql 5.7在宝塔中频繁停止主因是oom killer杀进程，需三步解决：先用dmesg和错误日志确认oom；再通过linux工具箱启用swap（2gb内存配2g swap）；最后在my.cnf中将innodb_buffer_pool_size设为物理内存50%～60%、max_connections调至80～100并禁用查询缓存。
MySQL 5.7 在宝塔面板里隔几分钟就显示“已停止”，点启动又能起来——这不是 MySQL 崩溃，而是被 Linux 内核 OOM Killer 杀掉了。解决它，Swap 是最直接有效的兜底手段，但必须配对使用，否则只是延缓问题。
查确认是不是 OOM 导致的自动停止
别急着开 Swap，先坐实原因。执行：dmesg -T | grep -i "killed process"，如果输出里有类似 Killed process 12345 (mysqld) 的记录，就 100% 是 OOM。再补一手：tail -n 30 /www/server/data/*.err，看有没有 InnoDB: mmap(...) failed; errno 12 或 Out of memory —— 这俩和 dmesg 结果一起出现，基本不用再怀疑。
用宝塔【Linux工具箱】快速启用 Swap
宝塔自带的 Swap 设置比手动敲命令更稳妥，尤其对新手。进【软件商店】→ 搜索并安装【Linux工具箱】→ 进入【设置】→ 左侧选【Swap/虚拟内存】。填大小时注意：
• 内存 ≤2GB → 设 2G
• 内存 4GB → 设 1–2G
• ≥8GB → 可不设，或只设 1G 应急
Swap 文件默认建在 /www/swap，确保该目录所在磁盘剩余空间 ≥ 所设值。点【确定】后，立刻执行 free -h，确认 Swap 行显示对应大小且 used 为 0。
Swap 不是万能药，必须同步压低 MySQL 内存上限
只加 Swap 不调 MySQL 配置，等于给油门踩到底的车加个备用油箱——迟早见底。进宝塔【软件商店】→ 找到 MySQL 5.7 → 【设置】→ 【配置修改】，在 [mysqld] 段落里重点改三项：
• innodb_buffer_pool_size = 1G（2GB 内存服务器）或 2G（4GB 内存），绝不超过物理内存 60%
• max_connections = 80（普通小站够用，别留 1000）
• 注释掉 query_cache_type 和 query_cache_size（MySQL 5.7 默认启用，但高并发下反而吃内存）
改完保存，务必点【重启 MySQL】，别只 reload。
守护脚本不能替代 Swap + 配置优化
有人用宝塔计划任务跑 pgrep -x mysqld &>/dev/null || /etc/init.d/mysqld start，这只能“事后补救”，无法阻止 OOM 发生。更糟的是：如果 mysqld 因 OOM 被杀后残留锁文件或 pid 文件，这种脚本会反复失败。真正有效的组合是：
• Swap 提供缓冲空间，让 OOM Killer 不那么激进
• innodb_buffer_pool_size 等参数把 MySQL 内存上限钉死
• 守护脚本只作为最后一道防线（比如每 30 秒轮询一次），且脚本里要加清理逻辑：rm -f /www/server/data/mysql.pid /www/server/data/ib_logfile* 再启动
否则，你看到的“自动恢复”，可能只是在重复失败。
Swap 开了、配置压了、脚本也挂了，MySQL 还停？那得去看 ps aux --sort=-%mem | head -10 —— 很可能 PHP-FPM 或某个 Python 进程正在后台偷偷吃光内存，MySQL 只是第一个被波及的。
