不能“修复”不一致，只能重建元数据对齐物理文件；innodb一致性校验依赖space_id、server_uuid、innodb_page_size与字典结构三者严格匹配，强行跳过校验易致崩溃或静默损坏。
直接结论：不能“修复”不一致，只能重建元数据对齐物理文件
仅靠修改 .frm 或 .ibd 文件本身无法解决崩溃引发的元数据与表空间不一致问题。InnoDB 的一致性校验发生在启动时和 IMPORT TABLESPACE 阶段，核心依赖 space_id、server_uuid、innodb_page_size 和字典中注册的表结构三者严格匹配。强行覆盖或跳过校验大概率导致崩溃或数据静默损坏。
为什么 mysqlfrm 解析出的 CREATE TABLE 语句常导入失败
mysqlfrm 只能还原 .frm 中的字段定义、索引名、主键约束等，但无法还原以下关键上下文：
-
ROW_FORMAT（如DYNAMICvsCOMPACT）——错配会导致IMPORT TABLESPACE报Tablespace is not encrypted but encryption flag is set -
KEY_BLOCK_SIZE和COMPRESSION设置——影响页布局，不一致会触发页校验和失败 - 字符集排序规则细节（如
utf8mb4_0900_as_csvsutf8mb4_unicode_ci）——可能让ALTER TABLE ... IMPORT TABLESPACE拒绝加载 - 外键约束、生成列、隐藏系统列（如
_rowid）——mysqlfrm --diagnostic常遗漏这些
验证方法：用 hexdump -C table.ibd | head -20 查找字符串 COMPACT 或 DYNAMIC，再比对 SHOW CREATE TABLE 输出中的 ROW_FORMAT 字段。
DISCARD + IMPORT TABLESPACE 失败后该查什么日志
每次 IMPORT TABLESPACE 失败都必须立刻停手，先看 error log 最后 20 行，重点关注三类线索：
-
InnoDB: Operating system error number 2→ 文件权限不对（应为mysql:mysql且chmod 640）或路径不存在 -
InnoDB: Space ID in file ./db/tbl.ibd is X, but in data dictionary it is Y→space_id不匹配，需用hexdump确认头信息，并检查是否误用了其他实例导出的.ibd -
InnoDB: Page checksum mismatch或Corrupted page found→.ibd文件已物理损坏，不能再尝试IMPORT，应转向底层页解析或放弃该文件
别反复重试：每失败一次，MySQL 可能残留未清理的锁或缓存状态，重启前务必确认 innodb_force_recovery 已清空，且没有 ib_logfile* 被旧进程占用。
MySQL 8.0+ 没有 .frm 后怎么重建表结构
8.0+ 移除了 .frm，表结构全存在系统表空间 mysql.ibd 和每个 .ibd 内嵌的 SDI（Serialized Dictionary Information）。若系统表空间损坏，单靠 .ibd 无法自动注册表：
- 先确认
.ibd是否支持 SDI 提取：运行ibd2sdi table.ibd -o table.sdi；失败则说明该文件是压缩/加密/Compressed ROW_FORMAT，SDI 不可用 - 成功提取后，用
jq '.dd_object.table_definition' table.sdi（需安装jq）解析 JSON，得到带完整字段类型、约束、注释的建表语句 - 注意
ibd2sdi输出的mysql_version字段必须与目标实例版本一致（如输出"8.0.33"，就不能在8.0.23实例上直接用） - 若
ibd2sdi报错或无输出，说明 SDI 已丢失或损坏，此时唯一可行路径是用 MySQL 5.7 兼容模式重建结构（字段数、主键、大字段位置），再暴力碰撞IMPORT
真正容易被忽略的是：哪怕 ibd2sdi 成功了，生成的语句里 ENGINE=InnoDB 后还必须显式加上 ROW_FORMAT=DYNAMIC（或对应值），否则 IMPORT 仍会因页格式不匹配失败。
