InnoDB崩溃后应先查错误日志定位根因，避免误设innodb_force_recovery；区分ibdata1、.ibd、redo log及8.0数据字典损坏场景，采取对应恢复策略，优先依赖备份而非强行修复。
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，立即停服并评估备份可用性。
