mysql频繁重启主因是外部约束或配置失配触发系统保护（如oom killer）或自愈逻辑；需据错误日志区分启动失败还是运行中崩溃，重点核查内存参数总和是否超限、磁盘空间、pid目录权限及systemd限制，并优先停自动重启、安全启动后立即备份。
MySQL频繁重启不是数据库“自己坏了”，而是系统或配置在拉响警报——90%以上的情况，根源不在MySQL代码，而在内存超限、磁盘满、PID目录无权限或systemd硬限制这些启动前就被卡住的环节。
先看错误日志，别猜原因
日志是唯一可信线索，跳过这步等于蒙眼修车：
- 查MySQL错误日志：
/var/log/mysqld.log（RHEL/CentOS）或/var/log/mysql/error.log（Ubuntu/Debian），用tail -n 100 /var/log/mysql/error.log快速定位最近几条报错 - 同步查系统日志：
dmesg -T | grep -i "killed process.*mysqld"，若输出含Out of memory: Kill process，基本锁定OOM Killer干的 - 重点盯这几行：
Cannot allocate memory for the buffer pool、InnoDB: Database page corruption、Can't create/write to file '/var/run/mysqld/mysqld.pid'——它们直接暴露卡点
内存参数总和是否远超物理内存
这是当前最常踩的坑：单个参数看着合理，加起来却把机器压垮：
-
innodb_buffer_pool_size设1.5G，sort_buffer_size设32M，max_connections为100 → 光排序缓冲就额外吃掉3.2G，还没算其他线程内存 - 真实可用内存看
free -h里的Available字段，不是free；cat /proc/meminfo里MemAvailable更准 - 验证配置合法性：
mysqld --defaults-file=/etc/mysql/my.cnf --validate-config，能提前发现语法错或不兼容项 - 临时止血：注释掉
Restart=on-failure（在/usr/lib/systemd/system/mysql.service里），防止循环重启干扰排查
检查启动前就被拦住的基础项
很多重启根本没进MySQL主流程，卡在“进门”环节：
- 磁盘空间：
df -h查数据目录所在分区，剩 - PID目录权限：
/var/run/mysqld/必须存在且mysql用户可写；ls -ld /var/run/mysqld确认归属，sudo chown mysql:mysql /var/run/mysqld修复 - systemd限制：
systemctl show mysql | grep Limit，重点关注LimitNOFILE（文件句柄）、MemoryLimit（内存上限），这些比MySQL自身配置更早生效 - swap关闭后更易OOM：用
free -m确认Swap是否为0；若物理内存仅2G，innodb_buffer_pool_size建议≤1G，而非盲目设70%
运行中崩溃 vs 启动失败，排查路径完全不同
时间戳对齐是关键判据：
- MySQL日志里重启时间，和
dmesg里Killed process时间一致 → 是被OOM Killer杀的，往内存调优走 - MySQL日志显示
mysqld_safe Starting mysqld daemon后几秒就退出，且无明显错误 → 往PID目录、磁盘空间、systemd限制查 - 日志出现
InnoDB: Database page corruption或Table 'xxx' is marked as crashed→ 需停库后用innodb_force_recovery=1启动，再导出数据
真正麻烦的不是某一行配置写错，而是多个资源约束叠在一起——比如systemd设了MemoryLimit=2G，而MySQL配置里innodb_buffer_pool_size=1.8G再加连接内存，实际跑起来瞬间超限。这种叠加效应最容易被忽略，得一项项拆开验。
