MySQL不会主动重启，所谓自动重启实为systemd等守护进程触发；OOM Killer日志、signal 9、exit code 137、kern.log硬件错误及systemd重启策略（如Restart=on-failure）是关键排查点。
MySQL进程被kill导致的自动重启
MySQL自己不会“主动重启”，所谓自动重启，99%是被系统或外部工具干掉后，由守护进程（比如systemd、supervisord）拉起来的。先确认是不是mysqld进程真的挂了再重启，而不是MySQL内部触发的重启。
查最近一次崩溃前的痕迹：
sudo journalctl -u mysql --since "2 hours ago" | grep -E "(killed|OOM|segfault|signal|exit)"
-
Out of memory: Kill process <code>mysqld这类日志说明内核OOM Killer动手了，不是MySQL问题，是内存配额不足 -
Received signal 9或Terminated基本等于被kill -9强杀，得查谁在调用kill命令（比如监控脚本、部署工具、定时清理任务） - 没看到
signal但有exited with code 137，也是OOM典型标志（128+9）
/var/log/kern.log里找OOM和硬件异常
内核日志才是OOM Killer动作的唯一权威记录，MySQL自己的错误日志（error.log）里基本不会写“我被杀了”，它只来得及记“正在关闭”。
重点搜这些：
sudo grep -i -E "(oom|kill|memory|hardware|uncorrectable|machine check)" /var/log/kern.log | tail -30
-
Out of memory: Kill process <code>mysqld(pid12345) score234—— 看score值，分数越高越容易被杀；同时间对比其他进程score，判断是否MySQL独占内存 -
Hardware error或Machine check events logged可能指向内存条故障或CPU过热，这类问题会导致内核直接终止进程，MySQL连写日志的机会都没有 - 如果
kern.log里完全没相关记录，但MySQL反复重启，要怀疑是否启用了restart=always的docker容器，或systemd配置了RestartSec=10这种激进策略
systemd服务配置偷偷改了重启策略
很多人以为MySQL是“自己崩了”，其实是systemd在背后兜底重启。检查真实配置来源：
systemctl show mysql | grep -E "(Restart|StartLimit)"
-
Restart=on-failure是默认值，但只要MySQL退出码不是0（比如被kill、core dump），就会触发重启 -
StartLimitIntervalSec=60+StartLimitBurst=5意味着1分钟内崩5次就放弃——如果看到start request repeated too quickly，说明已进入抑制状态，此时MySQL实际没在跑，只是你看不到报错 - 别只看
/etc/systemd/system/mysqld.service，优先运行systemctl cat mysql，它会显示最终生效的完整单元文件（可能来自/lib/systemd/system/或/etc/systemd/system/覆盖）
MySQL错误日志里真正有用的线索其实很少
MySQL的error.log对分析“为什么被杀”基本没用，但它能帮你排除“是不是自己崩的”。打开它，只盯三件事：
- 最后一行是不是
mysqld: Shutdown complete？如果是，说明是正常关闭流程走完的，大概率是被外部信号终止 - 有没有
InnoDB: Database was not shut down normally!？有，说明上次是crash，要继续查innodb_force_recovery相关日志或redo log头信息 - 有没有重复出现
Too many connections或Out of sort memory？这类错误本身不杀进程，但长期积累可能导致OOM，属于间接诱因
别在error.log里找“重启原因”，它不记谁发的kill，也不记内核事件。真要定位，kern.log和journalctl -u mysql才是第一现场。
