MySQL 8.0通过将元数据统一存入InnoDB事务表（如mysql.tables、mysql.columns）实现原子DDL，避免了5.7及之前.frm与ibdata1双源不同步导致的崩溃后“Table doesn't exist”等问题；ibd2sdi可解析.ibd中的SDI提取基础表结构，但无法还原外键、触发器等完整DDL。
因为 MySQL 8.0 把表结构元数据彻底收归 InnoDB 管理，用事务型系统表替代了松散、非事务的文件存储，从根本上解决元数据不一致和 DDL 崩溃残留问题。
为什么.frm文件导致崩溃后元数据错乱
在 5.7 及之前，.frm 是 Server 层独立生成的二进制文件，而 InnoDB 自己也在 ibdata1 里存一份表定义。两者不同步时（比如 ALTER TABLE 中断），.frm 可能已更新但引擎层没提交，或反过来——重启时 MySQL 会按 .frm 加载表，却找不到匹配的 InnoDB 字典项，直接报错“Table doesn't exist”或“Incorrect information in file”。这种双源管理是历史包袱，不是设计缺陷，而是架构割裂的必然结果。
数据字典如何用 InnoDB 表实现原子 DDL
MySQL 8.0 把所有元数据（库、表、列、索引、约束）都存进 mysql 库下的 InnoDB 表，例如：
mysql.tables mysql.columns mysql.indexes mysql.tablespaces
这些表本身受 ACID 保护，所以 CREATE TABLE 不再是「先写 .frm + 再建 ibd」两步，而是一次性插入多条字典记录 + 创建 .ibd，全部包裹在一个事务里。失败就全滚，成功才落盘。你执行 DROP TABLE 后立刻 kill mysqld，重启也不会残留空 .ibd 或孤儿 .frm。
ibd2sdi 工具能读出什么，又不能做什么
ibd2sdi 是唯一能从孤立 .ibd 文件中提取表结构的官方工具，但它只读取嵌入在文件头部的 SDI（Serialised Dictionary Information）段，内容包括：
-
"dd_object_type": "Table"、字段名、类型、长度等基础定义 - 主键/索引名、列顺序，但不含索引类型（BTREE/HASH）或表达式细节
- 不包含外键约束、触发器、分区规则等高级定义
- 如果表是 8.0.12 之前创建的，SDI 可能根本不存在（旧版本未默认写入）
也就是说：ibd2sdi 能帮你重建 CREATE TABLE 语句骨架，但无法还原完整 DDL；它不是万能恢复工具，只是应急补救手段。
直接复制 .ibd 文件为什么在 8.0 不再可靠
过去 DBA 常用「cp .ibd + 替换 .frm」恢复单表，这在 8.0 完全失效，原因有三：
-
.ibd文件头里的 SDI 和数据字典中的记录必须严格匹配，否则ALTER TABLE ... IMPORT TABLESPACE会报错Tablespace is not empty或Failed to open table - 目标实例的数据字典里没有对应
mysql.tables记录，IMPORT命令根本不会启动导入流程 - 即使强行跳过校验（如用 debug 版本），InnoDB 也会在打开表时校验
TABLE_ID和字典中的se_private_id，不一致直接拒绝访问
真正可行的路径是：先用 ibd2sdi 解析结构 → 手动创建同名空表 → 再执行 ALTER TABLE ... DISCARD TABLESPACE + IMPORT。漏掉任一环，表就不可见。
