mysql断电后无法启动的根本原因是innodb崩溃恢复机制失效导致表空间物理不一致；必须通过innodb_force_recovery抢出数据或用ibd2sql直接解析.ibd文件恢复。
MySQL断电后无法启动，根本原因在于 InnoDB 的崩溃恢复机制失效——ibdata1、ib_logfile0、ib_logfile1 与各 .ibd 文件之间的物理一致性被破坏，MySQL 启动时校验失败直接退出。此时不能靠“复制 .ibd 文件进新实例”就完事，必须分清：哪些表还能救、哪些已损坏、哪些只能靠 .ibd 单独解析。
为什么单纯复制 .ibd 文件会失败
因为 InnoDB 表空间不是独立存在的：.ibd 文件只存数据页和索引页，而表定义（DDL）、事务元数据、行格式、外键约束等都依赖 ibdata1（系统表空间）和数据字典。断电后若 ibdata1 损坏或版本不匹配，即使 .ibd 完好，MySQL 也会报：
[ERROR] InnoDB: Error: tablespace for 'test.t1' is missing.
常见错误现象包括：
- 服务启动几秒后自动停止，Windows 事件日志提示“本地计算机上的 MySQL 服务启动后停止”
- 错误日志中反复出现
Cannot read first page of 'xxx.ibd'或I/O error - 能启动但执行
SHOW TABLES时卡住，或查询某张表就导致 mysqld 崩溃
innodb_force_recovery 是第一道抢救线
它不修复文件，而是让 MySQL 跳过某些崩溃恢复步骤强行启动，目的是抢出还能读的数据。必须从 1 开始试，逐级加到 6（最高级），每级对应跳过的恢复动作不同：
-
innodb_force_recovery = 1：跳过回滚段恢复（最常用，多数可读表能出来） -
= 3：禁止插入缓冲合并，= 4：跳过重做日志应用 —— 此时只能SELECT，不能写入 -
= 5或= 6：禁用撤销日志和主键/二级索引加载，风险极高，可能漏数据
操作方式：
- 编辑
my.ini（Windows）或my.cnf（Linux），在[mysqld]下添加：innodb_force_recovery = 1 - 删除
ib_logfile0和ib_logfile1（否则启动必失败） - 重启服务；若成功，立刻用
mysqldump导出所有库（加--single-transaction） - 导出失败的表，单独记下名字，留待下一步用
ibd2sql处理
用 ibd2sql 直接解析 .ibd 文件导出 SQL
当 innodb_force_recovery 也无效，或表已损坏无法挂载时，ibd2sql 是唯一可行路径——它绕过 MySQL 引擎，直接读取 .ibd 文件的物理页结构，还原出 DDL + DML。
关键前提：
- 必须有 Python 3.7+ 环境（
python --version验证） -
.ibd文件本身未被覆盖或严重碎片化（断电后立即停机，别写入新数据） - 表引擎为 InnoDB（MyISAM 不适用）
常用命令示例（Windows CMD，管理员权限）：
python main.py D:\mysql\data\mydb\user.ibd --ddl
输出建表语句；再执行：
python main.py D:\mysql\data\mydb\user.ibd --sql
输出 INSERT 语句。如果想连删掉的数据也捞回来（例如误删后没 purge），加 --delete 参数：
python main.py D:\mysql\data\mydb\user.ibd --sql --delete
注意：ibd2sql 对 MySQL 8.0+ 的新页格式（如 DATA DIRECTORY、加密表）支持有限，遇到 Unknown page type 错误说明文件结构已不可识别。
最容易被忽略的三个细节
一是 ibdata1 不能丢：哪怕你只想恢复一张 .ibd，原始 ibdata1 也要保留，它是恢复上下文的锚点；二是权限问题：Windows 下解压 ibd2sql 后，CMD 必须以管理员身份运行，否则读 .ibd 会报 Permission denied；三是时间窗口：.ibd 文件一旦被操作系统回收或磁盘覆写，就彻底不可逆——断电后第一时间关机，别继续用那台机器。
