必须先查错误日志最开头几行，盯住InnoDB:开头的ERROR行；如出现“Database page corruption on disk”才是真损坏，需逐级尝试innodb_force_recovery=1～6导出数据后重建实例。
直接看日志最开头几行的 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。很多崩溃前都有明显预警：
-
[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 进程没清干净。日志只是起点，不是终点。
