MySQL异常关闭后应先查错误日志定位原因，再检查是否OOM、InnoDB损坏、配置冲突或磁盘故障；确认OOM需查dmesg和内存状态；InnoDB损坏可尝试innodb_force_recovery安全启动导出数据。
MySQL异常关闭后，首要任务是定位崩溃原因，而非直接重启服务。多数情况下，错误日志（error log）是唯一可靠线索，必须优先查看。
检查MySQL错误日志
MySQL启动失败或运行中意外退出时，不会主动提示具体原因，但会把关键信息写入错误日志。默认路径通常为：
- /var/log/mysqld.log（RHEL/CentOS系，使用systemd管理时）
- /usr/local/mysql/data/hostname.err（源码编译安装常见位置）
- /var/lib/mysql/hostname.err（Debian/Ubuntu系常用）
用red">tail -n 100 /path/to/error.log查看末尾最新记录，重点关注包含[ERROR]、InnoDB: Database page corruption、Out of memory、Cannot allocate memory、Aborting等关键词的行。
确认是否因内存不足被系统OOM Killer终止
Linux内核在内存严重不足时，会强制杀死占用内存最多的进程，MySQL常被选中。此时错误日志可能只显示“Killed”或无明显报错，需交叉验证：
- 执行dmesg -T | grep -i "killed process"，查找类似Killed process mysqld (pid 12345)的记录
- 检查系统内存压力：free -h 和 cat /proc/meminfo | grep -i "oom\|commit"
- 若确认是OOM，需调低innodb_buffer_pool_size（建议设为物理内存的50%~75%，避免与系统及其他服务争抢）
检查InnoDB表空间或日志文件损坏
InnoDB崩溃常见于redo log写入异常、ibdata1损坏或磁盘I/O故障。典型表现包括：
- 错误日志中出现InnoDB: Database page corruption on disk或Invalid log block checksum
- 启动卡在Starting crash recovery...阶段长时间无响应
- 尝试启动时提示Table 'mysql.plugin' doesn't exist等系统表缺失
可临时启用安全恢复模式启动（仅用于诊断）：
mysqld --innodb_force_recovery=1（数值1~6，从1开始尝试；值越高限制越多，6为最高，仅允许SELECT）
成功启动后立即导出数据，再重建实例。注意：innodb_force_recovery > 0 时禁止写入操作，且不能执行ALTER TABLE、DROP TABLE等DDL。
排查配置与硬件问题
以下两类问题易被忽略但高频发生：
- 配置冲突：如max_connections设得过高导致线程数超限；innodb_log_file_size修改后未删除旧日志文件就重启，引发校验失败
- 磁盘异常：使用dmesg | grep -i "ata\|nvme\|sd"检查是否有I/O错误；用smartctl -a /dev/sdX查看硬盘健康状态；确认/var/lib/mysql所在分区未满（df -h）
若近期做过升级（如MySQL 5.7 → 8.0）、参数调整或内核更新，建议回退变更并逐项验证。
