mysql自动重启主因有四：oom killer杀进程、systemd因配置错误重启、磁盘满触发watchdog、mysqld_safe弃用 wrapper 干扰排障；排查应先查dmesg、journalctl、df、ps，而非直接翻error.log。
MySQL 进程被系统 kill 导致自动重启，dmesg 显示 Out of memory: Kill process mysqld
这是最常见也最危险的自动重启原因：MySQL 没有崩溃，而是被 Linux OOM Killer 主动干掉的。它不属于 MySQL 自身故障，所以查 error.log 通常一片平静，反而 dmesg -T | grep -i "killed process" 会直接暴露真相。
根本原因是物理内存耗尽，内核被迫选择一个“高内存占用、低优先级”的进程终结——而 mysqld 常常中招。
- 立即检查：
dmesg -T | tail -50，重点找带Killed process mysqld和Out of memory的时间戳行 - 确认是否真被 OOM 杀：用
grep -i "oom\|kill" /var/log/syslog（Debian/Ubuntu）或/var/log/messages（RHEL/CentOS）交叉验证 - 别急着调大
innodb_buffer_pool_size：它可能正是内存超支的元凶；先看free -h和cat /proc/meminfo | grep -i "memavailable\|memfree"真实可用内存 - 临时缓解可加
vm.oom_kill_disable=1（不推荐），更稳妥的是限制mysqld能用的最大内存：在 systemd service 文件里加MemoryLimit=2G（需配合MemoryAccounting=true）
MySQL 配置错误触发 systemd 自动重启，systemctl status mysqld 显示 failed 后秒起
systemd 默认把 MySQL 设为 Restart=on-failure，只要进程退出码非 0 就拉起来。如果配置写错（比如 my.cnf 里拼错 bind-address 或指定不存在的 socket 路径），MySQL 启动失败 → systemd 立刻重试 → 表现为“闪退又自启”，看起来像“运行中重启”。
关键线索不在 MySQL 日志，而在 systemd 的启动上下文。
- 查最近一次真实启动失败原因：
journalctl -u mysqld --since "2 minutes ago" -n 100，注意开头几行的Starting MySQL Server...后紧跟着的报错 - 高频出错点：
socket路径权限不对（/var/run/mysqld/目录属主不是mysql）、datadir挂载点丢失、max_connections设得远超系统ulimit -n -
mysqld --defaults-file=/etc/my.cnf --verbose --help | grep "Default options"可确认实际加载了哪个配置文件，避免改了错的my.cnf - 停掉服务后手动运行：
sudo -u mysql /usr/sbin/mysqld --defaults-file=/etc/my.cnf --console，错误直接打到终端，比日志更及时
磁盘满导致 MySQL 写入失败，触发 watchdog 机制或 systemd fallback 重启
MySQL 无法写 binlog、redo log 或临时表时，可能卡住、拒绝新连接，甚至被 systemd 的 WatchdogSec 判定为“无响应”而杀掉重启。此时 df -h 往往比 error.log 更早给出答案。
尤其注意 /var/lib/mysql/、/var/log/mysql/ 和 /tmp（临时表默认位置）三个路径。
- 快速定位爆满目录：
df -h | grep -E "(mysql|log|tmp)"，再用du -sh /var/lib/mysql/* | sort -hr | head -5找大文件 - 常见罪魁：
binlog（没设expire_logs_days）、slow_query_log（开启但没轮转）、ibtmp1（大事务未提交导致膨胀） - 别直接
rmbinlog：用PURGE BINARY LOGS BEFORE '2024-01-01 00:00:00'或PURGE BINARY LOGS TO 'mysql-bin.000123' - 临时释放空间后，必须进 MySQL 执行
SHOW ENGINE INNODB STATUS\G，看TRANSACTIONS部分是否有长时间未提交事务，否则ibtmp1很快又涨
mysqld_safe 已弃用但仍在跑，它的自动重启逻辑会掩盖真实问题
MySQL 5.7+ 官方已弃用 mysqld_safe，但很多老部署仍通过它启停。它的设计是：只要 mysqld 进程消失，就无条件重启——不管崩溃原因，也不管是否刚修好配置。这会让“修复→测试→再崩”变成死循环。
判断是否在用它：ps aux | grep mysqld_safe，或者看 systemctl cat mysqld 里 ExecStart 是否调用了 mysqld_safe。
- 现代替代方案：直接用 systemd 管理
mysqld二进制，删掉mysqld_safe相关 wrapper - 若必须保留，至少关掉它的自动重启：
mysqld_safe --skip-grant-tables --syslog && echo "now check error log"，避免干扰排障 -
mysqld_safe的日志默认写进hostname.err，但它只记录“启动/停止”，不记录崩溃堆栈；真正的崩溃信号（如signal 11）只在error.log里 - 升级到 MySQL 8.0 后，务必迁走
mysqld_safe：它的--ledir、--open-files-limit等参数在新版已被 systemd 或 MySQL 内部接管
OOM、配置错、磁盘满、过时 wrapper —— 这四类问题占了 MySQL “自动重启” 的九成以上。查的时候别一头扎进 error.log 翻页，先看 dmesg、journalctl、df、ps，顺序错了，花两小时不如花两分钟。
