八成是内存不足触发OOM Killer强制杀进程；需同步启用Swap并调低innodb_buffer_pool_size、max_connections等参数，查错误日志确认“Killed process mysqld”等痕迹，再验证进程PID与内存占用是否稳定。
MySQL 8.0 在宝塔面板中频繁自动停止，**八成是内存不足触发系统 OOM Killer 强制杀进程，不是配置没保存或密码错了**。Swap 和 my.cnf 参数必须一起调，单改一个效果有限。
查日志确认是不是被系统 kill 掉了
先别急着改配置，直接看证据。OOM 杀进程会在错误日志里留下明确痕迹：
- 执行
tail -n 50 /www/server/data/*.err，重点找含Out of memory、Killed process mysqld或Cannot allocate memory的行 - 如果看到
mysqld: OOM killed process，那就不用往下看了——就是内存撑不住，得加 Swap + 压参数 - 日志路径也可能是
/var/log/mysql/error.log，宝塔界面里【软件管理】→ MySQL → 【错误日志】也能直接打开
加 Swap 不是“随便设个 2G”就完事
OVZ 架构的 VPS（比如某些廉价腾讯云/阿里云入门款）根本不支持 Swap，强行添加会失败；KVM 架构才能用。加之前先确认：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 运行
uname -r，输出带ovz字样就是 OVZ，跳过这步 - 运行
free -h看当前 Swap 是否为 0，是的话再操作 - 宝塔【Linux 工具箱】→ 添加 Swap，建议值：物理内存 ≤1GB 设 1GB，1–2GB 设 1.5GB，≥2GB 可不加（但建议保留 1GB 应急）
- Swap 文件默认生成在
/www/swap，确保/www分区剩余空间 ≥Swap 大小
my.cnf 关键参数必须同步压降
MySQL 8.0 默认内存胃口大，光加 Swap 不调参，服务启动后几小时照样被干掉。进宝塔【软件商店】→ MySQL → 【设置】→ 【配置修改】，只动这几项：
-
innodb_buffer_pool_size = 1G（2GB 内存机器），不能超过物理内存 50%，否则其他服务（如 Nginx、PHP）抢不到内存 -
max_connections = 80（中小站点够用），别留默认 151，每个连接至少吃 2–3MB -
wait_timeout = 600和interactive_timeout = 600，防空闲连接长期占资源（注意：这不是解决“服务崩溃”，是减少连接堆积） - 删掉或注释掉旧版残留的
sql_mode配置，MySQL 8.0 对严格模式敏感，错一条就初始化失败
重启后必须验证 mysqld 进程是否真稳住了
改完配置、加完 Swap，重启 MySQL 后别信面板上那个“运行中”图标：
- 立刻执行
ps aux | grep mysqld，确认进程 PID 持续存在，且启动时间不是“00:00”（说明刚起来就被杀了） - 跑
top看%MEM列，mysqld 占比应稳定在 40%–60%，如果冲到 90%+ 并快速上涨，说明参数还是没压住 - 观察 24 小时内是否再次停止——很多问题改完看似好了，其实是延迟爆发，真正稳住要扛过第一个流量高峰
Swap 和 my.cnf 是绑定动作，漏掉任意一环，MySQL 8.0 在低配机器上都只是“苟延残喘”。另外，宝塔自带的“MySQL 守护”计划任务对已崩溃的服务无效，它只能重启正在运行但卡死的服务，这点特别容易被忽略。
