MySQL频繁重启主因是资源不足、配置错误、磁盘故障或崩溃日志中的致命异常；须查错误日志定位诱因，核验内存、磁盘、文件句柄等系统资源，校准innodb_buffer_pool_size等关键参数，并排查硬盘SMART状态与内核OOM记录。
MySQL服务频繁重启，核心原因通常集中在资源不足、配置错误、磁盘问题或崩溃日志中隐藏的致命异常。不能只看“服务挂了”，要顺着错误日志往底层查。
紧盯错误日志定位直接诱因
MySQL每次异常退出前，基本都会在错误日志（error log）里留下关键线索。默认路径通常是：
/var/log/mysqld.log（RHEL/CentOS）或
/var/log/mysql/error.log（Ubuntu/Debian）或
/usr/local/mysql/data/hostname.err（源码安装）。
重点搜索这些关键词：
- Aborted connection —— 多为客户端异常断连，一般不致重启，但大量出现可能反映网络或应用层问题
- Out of memory 或 Killed by signal 9 —— 操作系统OOM Killer主动杀掉mysqld进程，说明内存严重超限
- InnoDB: Database page corruption —— 表空间损坏，可能由强制断电、磁盘故障或bug引发
- Table 'xxx' is marked as crashed —— MyISAM表损坏（虽已少用，但遗留系统仍存在）
- Cannot allocate memory for the buffer pool —— innodb_buffer_pool_size 设置过大，超出物理内存
检查系统资源是否被耗尽
MySQL不是孤立运行的，它依赖CPU、内存、磁盘I/O和文件描述符。频繁重启常是系统级瓶颈的外在表现：
- 用 free -h 和 cat /proc/meminfo 看真实可用内存，注意 Available 字段，而非仅看 free
- 执行 top -p $(pgrep mysqld) 观察单个mysqld进程的 RES/VIRT 内存占用是否持续飙升
- 运行 iostat -x 1 5 查看 %util 是否长期接近100%，同时关注 await 和 r/s、w/s，判断是否存在磁盘瓶颈
- 检查文件句柄限制：cat /proc/$(pgrep mysqld)/limits | grep "Max open files"，确认未被设为过低值（如1024）
验证MySQL关键配置是否合理
很多重启源于配置参数与实际环境严重不匹配，尤其以下几项需重点核对：
- innodb_buffer_pool_size：生产环境建议设为物理内存的50%–75%，绝不可超过总内存的80%
- max_connections：过高会导致连接内存（thread_stack × max_connections）暴增；结合 show status like 'Threads_connected' 实际峰值调整
- tmp_table_size 和 max_heap_table_size：二者需一致，且不宜设得过大（如 > 512M），否则大量复杂查询易触发磁盘临时表或OOM
- innodb_log_file_size：修改后必须停库删除旧日志文件再启动，否则会拒绝启动并报错
排查硬件与文件系统隐患
看似软件问题，有时根子在硬件：
- 运行 smartctl -a /dev/sdX 检查磁盘SMART状态，重点关注 Reallocated_Sector_Ct、Current_Pending_Sector
- 执行 dmesg -T | grep -i "mysql\|kill\|oom\|ext4\|xfs"，查看内核是否记录过OOM Killer日志或文件系统错误
- 确认MySQL数据目录所在分区是否有足够空间：df -h /var/lib/mysql（常见路径），剩余空间低于15%可能触发InnoDB保护性关闭
- 检查是否启用了不稳定的内核模块或容器环境（如早期Docker + overlay2）导致页缓存异常
