应查看崩溃前最后一段ERROR或FATAL日志，而非crash recovery日志本身；用tail -n 200或grep -B 5 -A 5定位“InnoDB: Starting crash recovery”上下文，再人工回溯10～20行找真正诱因。
直接看 hostname.err 末尾的崩溃现场，重点找 “InnoDB: Starting crash recovery” 和紧随其后的报错行——它不是 Recovery 过程本身出问题，而是 Recovery 启动前 MySQL 已经挂了，那行之前的最后一段 ERROR 才是真凶。
怎么快速定位崩溃发生前的最后一段错误日志
MySQL 崩溃后重启时会自动做 crash recovery，但 recovery 日志（如 InnoDB: Starting crash recovery）只是“善后动作”，不能告诉你为什么崩。真正的原因藏在 recovery 开始前的最后几行 ERROR 或 FATAL 里。
常见操作方式：
- 用
tail -n 200 /var/lib/mysql/hostname.err查看末尾 200 行（路径以show variables like '%log_error%';输出为准） - 配合
grep -B 5 -A 5 'InnoDB: Starting crash recovery' /var/lib/mysql/hostname.err，把 recovery 启动上下文拉出来，再人工往回翻 10～20 行 - 如果日志被轮转过，别只查
error.log，顺手看看error.log.1.gz（用zcat error.log.1.gz | grep -i "error\|fatal" | tail -n 10）
哪些错误信息一出现基本就能锁定崩溃主因
这些关键词出现在崩溃前日志中，通常意味着明确的失败路径：
-
Out of memory或Killed process mysqld：系统 OOM Killer 杀的，不是 MySQL 自己挂的——立刻去dmesg -T | grep -i "killed process"确认 -
InnoDB: Assertion failure in file：InnoDB 内部断言失败，大概率是 MySQL Bug 或数据页损坏，需核对版本是否已知缺陷（如 8.0.33 某些分区表场景） -
Tablespace is missing for table或Operating system error number 2：ibd 文件丢失或权限不对，检查ls -l对应表空间路径 -
Plugin 'innodb' init function returns error：InnoDB 初始化失败，常因innodb_force_recovery配置不当或 buffer pool 初始化异常
Crash Recovery 日志本身能说明什么
InnoDB: Starting crash recovery 后面的信息，反映的是上次 shutdown 是否干净，而不是本次崩溃原因：
- 如果看到
InnoDB: Doing recovery: scanned up to log sequence number XXX，说明 recovery 正常完成，不用干预 - 如果卡在
starting checkpoint或反复打印log scan，可能 redo log 损坏，此时应停止尝试启动，优先从备份恢复 - 若 recovery 成功但随后又报
Cannot open table mysql/user，说明系统表空间（ibdata1）或数据字典不一致，不是 crash recovery 的锅，是更底层的数据损坏
真正容易被忽略的点：crash recovery 是“被动触发”的，它不产生崩溃，只响应崩溃。很多人盯着 recovery 日志反复分析，却漏掉了它上面 30 行以外那条孤零零的 ERROR 1234 (HY000): Out of sort memory——那才是压垮数据库的最后一根稻草。
