InnoDB表物理冷备份恢复需严格满足三前提：MySQL完全停止、源目标主版本一致、表结构提前重建；必须执行FLUSH TABLES ... FOR EXPORT生成.cfg文件并拷贝.ibd与.cfg，再建同名表、DISCARD后IMPORT，且须校验版本、权限、统计信息与一致性。
INNODB 表的物理冷备份恢复不是“开箱即用”的一键操作，它要求你严格满足三个前提：MySQL 完全停止、源目标版本一致（或至少主版本相同）、表结构必须提前重建。跳过任一环节，ALTER TABLE ... IMPORT TABLESPACE 会直接报错 Tablespace is missing for table 或 Incorrect file format。
冷备份前必须执行 FLUSH TABLES ... FOR EXPORT
这不是可选步骤，而是 INNODB 表物理导出的强制握手协议。它干三件事：FLUSH 强制刷脏页到磁盘，避免备份中缺失最新变更；生成 .cfg 元数据文件（含表空间加密密钥、页校验信息等）；对表加全局读锁，防止备份期间写入导致 .ibd 文件不一致。
常见错误是只拷贝 .ibd 文件而忽略 .cfg —— 恢复时 MySQL 会拒绝导入，报错 Cannot import tablespace, cfg file is missing。即使你用的是 MySQL 5.7+，部分版本在 UNLOCK TABLES 后自动删掉 .cfg，务必在解锁前完成拷贝。
- 执行顺序必须是：
FLUSH TABLES city FOR EXPORT;→ 手动拷贝city.ibd和city.cfg→UNLOCK TABLES; - 不要用
mysqldump或SELECT INTO OUTFILE替代——它们产出的是逻辑备份，和冷备份的物理文件不可互换 - 若表启用了
ENCRYPTION='Y'，.cfg还包含密钥轮转信息，缺了就无法解密恢复
恢复时不能直接替换 .ibd 文件
直接把备份的 .ibd 放进 datadir 并启动 MySQL，服务大概率启动失败，或启动后该表显示为 CRASHED。正确路径是：先建同名空表（结构必须完全一致，包括 ROW_FORMAT、CHARSET、COLLATE），再用 DISCARD TABLESPACE 清空其表空间，最后 IMPORT TABLESPACE。
容易被忽略的细节：CREATE TABLE 语句必须来自原库 SHOW CREATE TABLE city 的输出，不能靠记忆重写——比如 TEXT 字段默认长度、TINYINT(1) 和 BOOLEAN 的映射、是否启用 STATS_PERSISTENT 都会影响 .ibd 校验。
- 恢复命令链：
CREATE TABLE city (...);→ALTER TABLE city DISCARD TABLESPACE;→ 拷贝city.ibd和city.cfg到对应数据库目录 →ALTER TABLE city IMPORT TABLESPACE; -
IMPORT前确保文件属主是mysql:mysql，权限为660，否则报错Operating system error number 13 - 若提示
Tablespace has unknown flags，说明源库和目标库的innodb_file_format或innodb_page_size不匹配
冷备份只适用于整表级恢复，且无法跨版本
冷备份本质是复制原始数据页，没有抽象层转换。这意味着它不能像 mysqldump 那样通过 SQL 解析兼容不同 MySQL 版本。MySQL 8.0.21+ 默认禁用 innodb_file_per_table=OFF 场景下的单表冷备，因为系统表空间（ibdata1）无法单独导出。
如果你的表在共享表空间里，或者使用了 MySQL 8.0 的新特性（如原子 DDL 日志、新的 redo log 格式），冷备份文件在旧版本上根本无法识别。反过来，5.7 备份的 .ibd 在 8.0 上恢复，可能因字典元数据格式变化而失败。
- 验证版本兼容性：运行
SELECT VERSION();对比源库与目标库，主版本号（如 5.7 vs 8.0）必须一致 - 确认存储引擎配置：
SHOW VARIABLES LIKE 'innodb_file_per_table';必须为ON，否则无法按表粒度冷备 - 跨平台迁移（如 Linux → Windows）不可行：
.ibd文件依赖操作系统页对齐和字节序，强行拷贝会触发Corrupted page错误
恢复后必须执行 ANALYZE TABLE 和检查一致性
冷备份恢复绕过了 MySQL 正常的数据加载流程，索引统计信息不会自动更新，查询计划可能严重劣化。更关键的是，IMPORT TABLESPACE 不校验外键约束、不重放 undo log，如果原表有未提交事务或崩溃前处于半更新状态，恢复后的数据可能逻辑不一致。
最简验证方式是查一行数据并对比 MD5 值，但生产环境建议走完整校验：
- 立即执行：
ANALYZE TABLE city;更新统计信息，避免后续查询走错索引 - 检查外键：
SELECT * FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'city';确认约束是否生效 - 若表参与了主从复制，恢复后需手动同步
GTID_EXECUTED或binlog位置，否则从库会跳过该表变更
真正耗时的从来不是拷贝文件本身，而是版本对齐、结构重建、权限修复和一致性验证——这些步骤无法跳过，也极少能自动化。所谓“极速”，只存在于理想前提全部满足的那一次成功恢复里。
