如何从MySQL错误日志判断崩溃原因-mysql教程-PHP中文网

必须先查错误日志最开头几行，盯住innodb:开头的error行；如出现“database page corruption on disk”才是真损坏，需逐级尝试innodb_force_recovery=1～6导出数据后重建实例。

如何从mysql错误日志判断崩溃原因

直接看日志最开头几行的 InnoDB: ERROR 行

MySQL 启动失败或崩溃后，真正致命的错误几乎总在日志文件最靠前（通常是第 1～5 行），不是末尾。跳过这步就查配置、调参数，大概率白忙活。

重点盯住以 InnoDB: 开头且带 ERROR 的行，例如：

InnoDB: Database page corruption on disk
InnoDB: The log sequence number in ibdata1 does not match
InnoDB: Failed to initialize transaction sub-system
InnoDB: Unable to lock ./ibdata1

这些不是警告，是判决书。每条对应不同处置路径：

InnoDB: Database page corruption on disk → 物理损坏，必须用 innodb_force_recovery 导出数据
The log sequence number in ibdata1 does not match → redo log 和数据文件 LSN 不一致，删掉 ib_logfile0 和 ib_logfile1 再试
Unable to lock ./ibdata1 → 多半是残留进程、权限错或文件被占用，先 ps aux | grep mysqld 杀净，再检查 chown mysql:mysql /var/lib/mysql

区分“启动失败”和“运行中崩溃”

错误日志里没写清楚 MySQL 是挂了还是根本没起来。得靠上下文判断：

如果日志结尾是 mysqld: ready for connections，之后某天突然出现 Shutting down 或空白段落 → 是运行中崩溃，要结合 dmesg -T | grep "killed process.*mysqld" 看是否被 OOM Killer 干掉
如果日志从头到尾没出现 ready for connections，最后几行卡在 Starting crash recovery 或报 Cannot allocate memory for the buffer pool → 启动失败，优先查 innodb_buffer_pool_size 是否超物理内存、datadir 权限是否对
如果日志里反复出现 Aborted connection 且数量暴增 → 很可能是应用连接泄漏，积累到半夜触发资源耗尽，不是数据库自身崩溃

别只搜 ERROR，WARNING 常是前兆

MySQL 8.0+ 默认 log_error_verbosity=2，会同时记 ERROR 和 WARNING。很多崩溃前都有明显预警：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

[Warning] Memory allocation failed; aborting → 紧接着就是 OOM 或服务退出
[Warning] Disk is full 或 No space left on device → 下一条很可能就是 InnoDB: Operating system error number 28
[Warning] Too many connections → 若持续出现，可能引发连接队列阻塞、线程耗尽，最终服务无响应

用 grep -i "error\|warning\|failed\|cannot" /path/to/error.log | tail -n 30 一次性抓关键线索，比单搜 ERROR 更有效。

确认日志本身是否真被写进去了

很多“查不到原因”，其实是日志压根没生成。常见断点：

log_error 指向的目录不存在，或 mysql 用户无写权限 → 启动静默失败，连错误提示都不留
log_error_services 被误设成 log_sink_null 或漏了 log_sink_internal → 日志只打到 systemd journal（journalctl -u mysqld），你却在找 .err 文件
配置改了但没重启服务，或用了 SET PERSIST 却忘了 mysqld-auto.cnf 优先级高于 my.cnf → 实际生效的路径和你以为的不一致

验证方法：登录后执行 SELECT @@GLOBAL.log_error; 和 SELECT @@GLOBAL.log_error_services;，再 ls -l $(SELECT @@GLOBAL.log_error) 看文件是否存在、大小是否增长。

真正难的不是找到那行报错，而是判断它是不是表象——比如 Table 'mysql.plugin' doesn't exist 看似系统表丢失，实则是 ibdata1 损坏导致元数据加载失败；又比如 Address already in use 表面是端口冲突，背后可能是上一次崩溃后残留的 mysqld 进程没清干净。日志只是起点，不是终点。