17370845950

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，立即停服并评估备份可用性。