mysqldump会漏掉孤儿表，因其仅导出information_schema.tables中状态为'base table'或'view'的表，而孤儿表（.frm存在但数据字典无记录）在该视图中完全不可见。
为什么 mysqldump 会漏掉孤儿表
因为 mysqldump 默认只导出 information_schema.TABLES 中状态为 'BASE TABLE' 或 'VIEW' 的对象，而孤儿表（orphaned table）——即 .frm 文件存在但 InnoDB 数据字典中无对应记录的表——在 information_schema 里根本不会出现。它既不是有效表，也不被视作损坏表，mysqldump 完全感知不到它的存在。
典型场景：直接拷贝 .frm 文件到 datadir、强制删除 ibdata1 后重建、或异常关机导致数据字典未同步更新，都可能留下这种“影子表”。迁移时若只依赖 mysqldump，这些表的数据就彻底丢失。
如何识别并定位孤儿表
不能靠 SHOW TABLES 或 SELECT * FROM information_schema.TABLES 查——它们查不到。必须手动比对文件系统与数据字典：
- 先查当前库下所有
.frm文件：ls /var/lib/mysql/your_db/*.frm | xargs -n1 basename | sed 's/\.frm$//' | sort - 再查数据字典中该库实际注册的表：
SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' ORDER BY TABLE_NAME; - 用
comm -23或简单 diff 比对两个列表，差集就是疑似孤儿表名 - 进一步确认：进入
/var/lib/mysql/your_db/，对每个疑似表名检查是否存在对应.ibd文件；若只有.frm没有.ibd（且非分区表），基本可判定为孤儿表
修复孤儿表的实操路径（仅限 InnoDB，且需原 .ibd 仍存在）
如果迁移前你保留了完整的 datadir（包括原始 .ibd 文件），且 MySQL 版本兼容，可以尝试人工重建数据字典引用：
- 停止 MySQL 服务
- 把孤儿表的
.frm和.ibd文件复制回目标库对应目录（确保属主为mysql:mysql） - 启动 MySQL 时**不加任何 force_recovery**，观察错误日志是否报
Tablespace is missing for table类提示 - 若报错，登录后执行：
CREATE TABLE your_table (...) ENGINE=InnoDB;（结构必须与原表完全一致，可通过原.frm反推或从备份 SQL 中提取） - 然后运行：
ALTER TABLE your_table DISCARD TABLESPACE;→ 替换同名.ibd文件 →ALTER TABLE your_table IMPORT TABLESPACE;
注意：IMPORT TABLESPACE 要求 .ibd 的 space_id 与当前实例匹配，若源库曾多次重建或使用过 innodb_file_per_table=OFF，此法大概率失败。
更现实的兜底方案：跳过逻辑导出，改用物理层抢救
当孤儿表数量少、.ibd 文件完好、且你无法还原原表结构时，与其在 mysqldump 上硬扛，不如直接从文件提取数据：
- 用
strings快速扫描.ibd文件看是否有可读字段名或样本值：strings your_table.ibd | head -50 - 若结构较清晰，可用 Percona 的
innodb-tools（如ibd2sql）解析：ibd2sql -o /tmp/output your_table.ibd - 若只有
.frm没有.ibd，说明数据已不可恢复——此时唯一能做的，是用mysqlfrm工具（MySQL Utilities）从.frm提取建表语句：mysqlfrm --server=root@localhost --diagnostic /path/to/your_table.frm
真正麻烦的不是技术操作，而是没人会在迁移前专门去扫一遍 .frm 和 information_schema 的差异。等发现数据不全，往往备份已覆盖，只能靠文件残留碰运气。
