MySQL InnoDB 崩溃后无法启动：检查 innodb_force_recovery
是否被误设
InnoDB 引擎报错导致 MySQL 启动失败，常见于错误日志中出现
InnoDB: Database page corruption on disk或
Cannot continue operation。此时第一反应常是启用
innodb_force_recovery，但这个参数一旦设为非 0 值（尤其是 ≥4），MySQL 会禁止写入、甚至跳过事务恢复关键步骤，反而让后续恢复更困难。
innodb_force_recovery=1～
3仍允许部分 SELECT，但已禁用 INSERT/UPDATE/DELETE/DDL；设为
4及以上时，连
DROP TABLE都会被拒绝，且不加载 undo log —— 这意味着你无法通过导出再重建来救数据 正确做法是：先确认错误日志里最早出现的 InnoDB 错误行（搜索
[ERROR] InnoDB），再决定是否启用 recovery；若只是临时起服务查数据，应搭配
mysqldump --single-transaction --skip-lock-tables立即导出，之后立刻停服、清空
innodb_force_recovery再重启 该参数不能动态设置，必须写在
my.cnf的
[mysqld]段并重启生效；修改后务必验证
SELECT @@innodb_force_recovery;返回值是否符合预期
表空间文件损坏：区分 ibdata1
和独立表空间 .ibd
的修复路径
InnoDB 表空间损坏不是单一问题，要先判断损坏对象：是系统表空间
ibdata1（含 data dictionary、undo logs、change buffer），还是某张表的独立表空间文件（如
db1/t1.ibd）。两者修复逻辑完全不同。 若
ibdata1损坏（错误日志含
innodb_checksum_algorithm mismatch或
Failed to read from the .ibd file），基本无安全修复手段；必须依赖最近一次完整备份 + binlog 增量恢复；强行用
innodb_force_recovery=6启动并导出，大概率漏掉元数据或产生乱码 若仅单个
.ibd文件损坏（错误提示指向具体表名，如
Table 'db1.t1' not found in engine），可尝试用
ALTER TABLE t1 DISCARD TABLESPACE;删除损坏的
.ibd，再用备份的
.ibd+ 对应
.frm（MySQL 5.7）或
CREATE TABLE ... TABLESPACE = innodb_file_per_table（8.0）重新导入 注意：MySQL 8.0 默认关闭
.frm文件，元数据全存在 data dictionary 中；若只丢了
.ibd但表结构还在，可用
CREATE TABLE t1 LIKE t1_backup;先重建结构，再
DISCARD+
IMPORT TABLESPACE
事务日志（redo log）异常：ib_logfile0
/ib_logfile1
不匹配的典型表现
MySQL 启动时卡在
InnoDB: Starting crash recovery或直接报
Log sequence number in ibdata files does not match log sequence number in ib_logfiles!，基本锁定为 redo log 文件与系统表空间 LSN 不一致。这通常发生在强制 kill mysqld 进程、磁盘满未清理、或手动替换过
ib_logfile*文件之后。 不要手动删除或重命名
ib_logfile0/
ib_logfile1；MySQL 启动时会校验其大小和 header 中的 LSN，不匹配则拒绝启动 安全做法是：停止 MySQL → 备份整个
datadir→ 删除
ib_logfile*（不是
ibdata1！）→ 修改配置中
innodb_log_file_size保持与原值一致（可通过
SHOW VARIABLES LIKE 'innodb_log_file_size';查）→ 重启；MySQL 会自动重建 log 文件并重放未刷盘的事务 如果磁盘空间不足导致 redo 写失败，错误日志会出现
OS error code 28: No space left on device；此时需先清理磁盘（尤其
/tmp和
datadir所在分区），否则即使删了 log 文件也启动不了
MySQL 8.0+ Data Dictionary 损坏：比 5.7 更难绕过的元数据故障
MySQL 8.0 将表定义、列信息、外键等全部存入内部表空间
mysql.ibd和系统表
mysql.innodb_table_stats等，不再依赖文件系统级的
.frm。一旦这部分损坏，
SHOW TABLES可能返回空，或报
Table 'mysql.innodb_table_stats' not found，但
SELECT * FROM information_schema.tables却能看到记录 —— 这说明 data dictionary 已不一致。 无法用传统方式修复：
mysql_upgrade在 8.0+ 已废弃；
mysqld --initialize会清空整个 data dictionary，不可用于生产环境 唯一可行路径是使用官方工具
mysqld --bootstrap+ SQL 脚本重建字典（需严格按 MySQL 源码中
share/english/errmsg.sys和
scripts/mysql_system_tables.sql版本匹配），实操门槛极高；绝大多数情况应直接从物理备份（xtrabackup）或逻辑备份（mysqldump）恢复 日常预防：避免直接操作
mysql库下的 InnoDB 表（如手动
UPDATE mysql.innodb_table_stats）；开启
innodb_redo_log_encrypt=OFF（默认关闭）可降低加密相关崩溃风险
SELECT table_name, engine, table_rows FROM information_schema.tables WHERE table_schema = 'mysql' AND engine = 'InnoDB';
这条语句本身可能触发 data dictionary 访问异常；若执行卡住或报错，基本可判定字典层已受损 —— 此时别再执行任何 DDL/DML，立即停服并评估备份可用性。
