MySQL服务每日凌晨1:30左右自动停止需手动重启，求助排查原因

你好，先帮你理一理目前的情况，再给你几个实用的排查方向：

首先要注意的是，你贴出来的日志其实是MySQL启动时的记录（能看到starting as process 1682的提示），并不是服务停止瞬间的日志——这就是你没找到触发原因的核心问题，得去看停止前的日志内容才行。

下面是具体的排查步骤：

• 先找到MySQL的错误日志文件（通常路径是/var/log/mysql/error.log，或者MySQL数据目录下的同名文件），重点查看每天01:30前几分钟的日志，这里面大概率会记录服务终止的具体原因，比如内存耗尽、进程崩溃、异常中断等。
• 检查服务器的系统日志（比如/var/log/syslog或者/var/log/messages），如果MySQL是被系统的OOM Killer（内存不足自动回收进程的机制）杀掉的，系统日志里会有明确的记录。毕竟你有15-20个WordPress站点，凌晨可能有多个站点同时执行备份、wp-cron定时任务，导致内存占用飙升触发系统回收。
• 排查服务器上的定时任务：用crontab -l查看当前用户的定时任务，再检查/etc/cron.d/、/etc/cron.hourly/等目录下的系统定时任务，看看有没有在01:30左右执行的脚本，比如备份、清理类脚本，会不会误杀了MySQL进程，或者占用过多资源导致MySQL无法正常运行。
• 调整MySQL的配置项，解决日志里的警告（虽然不一定是直接原因，但能减少潜在风险）：
  • max_allowed_packet你设置了100G，被系统自动调整到1G，这个值过大容易占用过多内存，建议改成64M或128M（足够大部分WordPress场景使用）；
  • 日志提示NO_ZERO_DATE等SQL模式要配合严格模式使用，未来会合并到严格模式，建议开启严格模式提升兼容性；
  • 开启NO_AUTO_CREATE_USERSQL模式，提升数据库安全性。

另外，多个WordPress站点的定时任务叠加也是常见诱因——比如多个站点同时在凌晨执行更新、备份、数据清理，会导致数据库连接数暴增、资源占用过高，进而引发MySQL服务异常。

备注：内容来源于stack exchange，提问作者BenUK