不能直接恢复。千万级大表的.ibd文件单独存在时，必须经discard tablespace+停库+替换文件+import tablespace完整流程，因innodb强制要求表定义与表空间严格匹配，且space_id、lsn、页校验等内部状态不一致会导致tablespace mismatch、静默跳过或崩溃。
不能直接恢复。千万级大表的 .ibd 文件单独存在时，无法“直接”加载进运行中的 MySQL 实例——InnoDB 强制要求表定义（.frm 或数据字典）与表空间（.ibd）严格匹配，且必须经过 DISCARD TABLESPACE + 停库 + 替换文件 + IMPORT TABLESPACE 这套完整流程，跳过任何一步都会失败。
为什么不能跳过停库和 DISCARD/IMPORT 流程？
MySQL 进程在运行时会缓存表元数据、space_id、页校验等关键信息。.ibd 文件不是普通数据文件，它包含 InnoDB 页头、事务 ID、LSN、space_id 等内部结构。强行复制覆盖正在使用的 .ibd，会导致：
-
Tablespace mismatch错误：新.ibd的space_id和当前表定义不一致 -
InnoDB: Ignoring table xxx：MySQL 启动时发现元数据损坏，静默跳过加载，日志里只有一行警告，没报错但表不可见 - 崩溃或 hang 住：尤其在大表下，InnoDB 检查 LSN 或页校验失败时可能卡在 recovery 阶段
千万级表恢复前必须确认的三件事
大表对一致性、权限、磁盘 I/O 更敏感，出错成本极高：
- 确认原表引擎是
InnoDB：执行SHOW CREATE TABLE your_table\G，若看到ENGINE=MyISAM或ENGINE=Memory，这条路走不通——IMPORT TABLESPACE仅支持InnoDB - 确认
.ibd文件完整且未被截断：用ls -l your_table.ibd对比原始大小；用hexdump -C your_table.ibd | head -20查看前几行是否含有效 InnoDB 页头（如45 72 72 6f 72 20 6c 6f 67不是开头，正常是00 00 00 00 00 00 00 00+ space_id） - 确认目标库 MySQL 版本 ≥ 原库版本：MySQL 8.0 写出的
.ibd无法导入 5.7；但 5.7 的.ibd在 8.0 中导入需额外关闭innodb_strict_mode，否则报Invalid tablespace flags
实际恢复步骤中容易被忽略的关键操作
不是按顺序敲命令就完事，每个环节都有硬性约束：
- 必须先在目标库创建**同名空表**，且字段数必须和原表一致（哪怕类型全写成
VARCHAR(255)）：靠错误日志反推列数——启动带innodb_force_recovery=1的实例，覆盖.frm后查error.log，找类似InnoDB: Table db/your_table contains 3 user defined columns in InnoDB, but 12 columns in MySQL，那个 “12” 就是真实字段数 -
ALTER TABLE your_table DISCARD TABLESPACE必须成功执行，且确认对应.ibd文件已被删除（只是逻辑删，磁盘上还在）；否则后续IMPORT会因文件冲突失败 - 替换
.ibd后，必须用chown mysql:mysql your_table.ibd+chmod 660 your_table.ibd：Linux 下属主不对，MySQL 启动时不会报错，但IMPORT时提示Operating system error number 13 - 执行
ALTER TABLE your_table IMPORT TABLESPACE前，确保该表没有活跃事务、没被加锁；大表导入耗时长，期间不要中断连接，也不要执行其他 DDL
真正麻烦的从来不是命令本身，而是 .ibd 里的 space_id、LSN、page_size、checksum_mode 这些隐式状态，它们不显示在 SQL 里，却决定恢复成败。别信“覆盖就生效”的说法——InnoDB 不是文件系统，它是带状态的存储引擎。
