能救，但必须满足mysql服务能启动、innodb_file_per_table=on、有完好的.ibd文件三个硬条件；其他情况如ibdata1损坏或mysql完全起不来则不可行。
能救，但必须满足三个硬条件：MySQL服务能启动、目标表用的是innodb_file_per_table=ON、你手上有完好的.ibd文件——缺一不可。其他情况（比如ibdata1损坏或MySQL完全起不来），这条路走不通。
确认 MySQL 服务是否“半活着”
这是整个救援的前提。如果 MySQL 进程根本启不动，ALTER TABLE ... IMPORT TABLESPACE 就没机会执行；但如果报错后还能进客户端（哪怕多数表查不了），就还有操作窗口。
- 执行
mysql -u root -p，看能否连接成功；连不上就先别往下试 - 运行
SHOW DATABASES;，确认库名可见；再进对应库执行SHOW TABLES;，看表名是否还在（很多“失踪”场景下表名仍显示） - 查关键变量：
SELECT @@innodb_file_per_table;必须返回1；否则说明表空间混在ibdata1里，单个.ibd文件无法独立恢复 - 错误日志里如果反复出现
Tablespace is missing for table或Cannot read first page of '*.ibd'，属于典型的数据字典脱钩，适合本方案
重建表结构必须严丝合缝
你不能随便写个 CREATE TABLE 就导入——字段顺序、类型、长度、索引、ROW_FORMAT、甚至字符集都得和原表完全一致，否则 IMPORT TABLESPACE 会直接崩溃 MySQL 进程。
- 优先从备份、
mysqldump -d输出、或开发/测试环境导出SHOW CREATE TABLE t1\G拿到原始建表语句 - 如果没有，且 MySQL 还能查系统表，试试：
SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't1';看是否残留部分元数据 - 若完全无结构信息，可尝试用
ibd2sdi --dump-file t1.sdi t1.ibd解析.ibd文件自带的 SDI（Schema Definition Information）——但仅限 MySQL 8.0+，且要求该.ibd文件未被截断或覆盖过 -
ROW_FORMAT特别关键：用SHOW TABLE STATUS LIKE 't1'\G查原表（如有），或对比同库其他表；建表时显式加上ROW_FORMAT=DYNAMIC或COMPACT，不能依赖默认值
执行 DISCARD + IMPORT 的实操要点
两条 SQL 看似简单，但路径、权限、顺序错一步就会失败，且可能引发实例重启。
- 先关外键检查：
SET FOREIGN_KEY_CHECKS = 0;，避免建表或导入时因外键约束中断 - 建好空表后立刻执行：
ALTER TABLE t1 DISCARD TABLESPACE;—— 这会删掉当前表对应的.ibd文件（注意：不是你手里的那个！） - 把备份来的
t1.ibd文件复制到正确路径：cp t1.ibd /var/lib/mysql/mydb/（路径用SHOW VARIABLES LIKE 'datadir';确认） - 改权限：
chown mysql:mysql /var/lib/mysql/mydb/t1.ibd（Linux）或确保 MySQL 服务账户有读写权（Windows） - 最后执行：
ALTER TABLE t1 IMPORT TABLESPACE;—— 成功则无返回；失败会报错并写入 error log，常见如Incorrect key file for table（索引不匹配）、Space ID mismatch（.ibd文件被挪动过或来自不同实例）
最容易被忽略的两个致命细节
一是 .ibd 文件不能是“冷拷贝”自已停止的 MySQL 实例——它必须来自正常关闭（或至少是 flush tables）后的状态，否则页内脏数据未刷盘，IMPORT 后数据可能不一致甚至崩溃；二是整个过程必须在同一个 MySQL 主版本号下操作（比如 8.0.33 导入到 8.0.33，不能跨 8.0 → 8.4），小版本差异也可能触发校验失败。
