MySQL频繁重启主因是外部约束或配置失配触发系统保护（如OOM Killer）或自愈逻辑；需据错误日志区分启动失败还是运行中崩溃，重点核查内存参数总和是否超限、磁盘空间、PID目录权限及systemd限制，并优先停自动重启、安全启动后立即备份。
MySQL服务频繁重启，核心问题通常不是数据库本身“容易坏”，而是外部约束或配置失配触发了系统级保护机制（比如OOM Killer杀进程）或服务自愈逻辑。关键要分清是“启动失败后反复拉起”，还是“运行中突然崩溃再重启”——两者的排查路径完全不同。
看错误日志，定位第一现场
日志是唯一可信线索，别跳过这步：
- 先查 MySQL 错误日志：默认路径如 /var/log/mysql/error.log 或 /var/log/mysqld.log，用 tail -n 100 /var/log/mysql/error.log 快速看最近报错
- 再查系统日志：MySQL 被强制终止时，内核会记一笔，执行 dmesg -T | grep -i "killed process.*mysqld"，若输出类似 Out of memory: Kill process XXX (mysqld)，基本可锁定内存溢出
- 注意时间戳对齐：MySQL 重启时间和系统日志里的 kill 时间是否一致，能帮你判断是主动退出还是被干掉
重点查内存和配置是否“打架”
这是当前最常见原因——参数设得太大，而物理内存撑不住：
- 检查关键内存参数总和是否超标：innodb_buffer_pool_size + sort_buffer_size × max_connections + read_buffer_size × max_connections 等，很容易远超可用内存
- 举个典型例子：buffer_pool 设 1.5G，再配上 5 个连接、每个 sort_buffer_size=32M，光这部分就额外吃掉 160MB；并发一高，瞬间 OOM
- 验证配置合法性：运行 mysqld --defaults-file=/etc/mysql/my.cnf --validate-config，能提前发现语法错误或不兼容参数
检查资源与权限基础项
很多重启其实卡在启动前的“进门”环节：
- 磁盘空间：df -h 查数据目录所在分区，满或只剩几MB 会导致 mysqld 启动失败并循环重试
- PID 文件目录权限：比如 /var/run/mysqld/ 目录不存在，或 mysql 用户无写入权，服务无法生成 pid 文件，就会反复退出重试
- systemd 限制：检查 /usr/lib/systemd/system/mysql.service 中是否有硬性限制如 LimitNOFILE=5000 或 MemoryLimit，这些可能比 MySQL 自身配置更早掐断进程
快速止血与数据保全策略
服务还在闪退？先保住数据，再修根因：
- 临时停掉自动重启：运行 sudo systemctl stop mysql，再编辑 service 文件注释掉 Restart=on-failure，防止干扰排查
- 尝试安全启动：加 --skip-grant-tables 或设置 innodb_force_recovery=1（需改 my.cnf），跳过权限校验或损坏页加载，争取一次成功启动机会
- 启动成功后立即备份：mysqldump --all-databases --single-transaction > backup.sql，哪怕只是临时导出，也比反复重启丢数据强
