mysqlfrm解析失败主因是版本不兼容、诊断模式缺失字符集映射、不支持生成列/JSON/新排序规则及特殊表名转义；应优先用--server连接同版本实例，并结合错误日志反推字段类型。
只要 .ibd 文件还在，且 MySQL 是 5.7 版本、启用了 innodb_file_per_table=ON，就完全能靠 .frm 文件重建结构——但前提是别直接用文本编辑器打开它，也别指望 mysqlfrm 一跑就出完整 DDL。
为什么 mysqlfrm 工具经常解析失败或字段类型不准
mysqlfrm 默认走的是“启动临时实例 + 加载 .frm”的路径，依赖本地 MySQL 安装环境和版本兼容性。实际中常见问题包括：
- MySQL 小版本不一致（比如用 5.7.32 的
mysqlfrm解析 5.7.25 的.frm），导致字符集字段读错，VARCHAR变成TEXT，TIMESTAMP缺少默认值 - 遇到带生成列（generated column）、JSON 字段或新引入的
utf8mb4_0900_as_cs排序规则时，--diagnostic模式会跳过或报错，而默认模式压根不识别 - 表名含特殊字符（如连字符、中文）或数据库名用了反引号包裹，
mysqlfrm输出的CREATE TABLE语句里没转义，直接执行会语法错误
建议优先用 mysqlfrm --server=root@localhost:3306 --diagnostic your_table.frm 获取基础字段数和类型框架，再人工对照错误日志校验。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
用错误日志反推字段结构的实操步骤
当 .frm 丢失，只剩 .ibd，核心思路是让 MySQL 自己“吐”出结构信息。关键不是猜，而是制造可控错误：
- 在同名数据库下建一个字段数相同但类型全设为
INT的空表，引擎必须是InnoDB，字符集用utf8mb4 - 停掉 MySQL，把原始
.ibd文件复制进该表对应目录，替换新生成的.ibd；同时把备份的.frm（如有）也一并替换 - 启动 MySQL 前，在配置文件加
innodb_force_recovery=1，然后启动。此时访问该表大概率报错，但错误日志（mysqld.log）里会出现类似Column 3 is VARCHAR(255), but got INT的提示——这就是真实字段类型的线索 - 根据日志逐列调整建表语句，每次改完重启 + 测试，直到
SELECT COUNT(*) FROM table_name不再报错
替换 frm/ibd 后卡在 “Tablespace mismatch” 错误怎么办
这是最常卡住的环节，错误信息通常是：Tablespace mismatch for table 'db_name/table_name'. Cannot open table from its tablespace.
- 根本原因是
.ibd文件头里记录的表空间 ID（space_id）和当前 MySQL 数据字典里该表的 space_id 不一致。不能靠手动修改二进制文件，风险极高 - 正确做法：先用
ALTER TABLE table_name DISCARD TABLESPACE;清掉数据字典里的旧 space_id 记录，再执行ALTER TABLE table_name IMPORT TABLESPACE; - 执行
IMPORT前，确保.ibd文件权限是mysql:mysql，且文件大小非零；如果提示Invalid checksum，说明innodb_force_recovery级别不够，需逐步试2～4，但超过4会禁用 INSERT/UPDATE，只读可用
真正难的不是步骤本身，而是每一步都得看日志、比对字段偏移、确认 space_id 是否同步——这些细节不会写在任何官方文档里，但漏掉任意一个，表就永远挂不上。
