MySQL元数据字典损坏指数据库无法识别自身表结构，核心是重建字典与物理文件的映射关系；需先排除文件丢失或物理损坏，再通过IMPORT TABLESPACE修复独立系统表，严重时须初始化新系统库并迁移权限数据。
MySQL元数据字典损坏（如 INFORMATION_SCHEMA、mysql 系统库表结构错乱或不可见）不是“数据丢了”，而是数据库自己“认不出自己的表”了——这种情况下 SHOW TABLES 可能正常，但 SELECT 报 Table doesn't exist，mysqldump 失败，甚至 SHOW CREATE TABLE 直接报错。恢复的关键不是重建数据，而是重建字典与物理文件的映射关系。
确认是否真为元数据字典损坏而非文件丢失
先排除更基础的问题：如果 .ibd 或 ibdata1 文件被删、权限异常或磁盘报错，后续所有操作都无效。必须先验证：
- 检查错误日志里是否有
InnoDB: Operating system error number 2（文件不存在）或Corrupted page found（物理页损坏）——这类属于文件级损坏，走innodb_force_recovery路线 - 执行
SELECT * FROM mysql.innodb_table_stats;，若报Table doesn't exist但SHOW TABLES FROM mysql;能列出该表名，大概率是字典元数据损坏 - 用
mysqlcheck -c mysql innodb_table_stats检查系统表状态（注意：InnoDB 表不支持完整校验，但能暴露部分元数据不一致）
用 ALTER TABLE ... IMPORT TABLESPACE 修复单个系统表
MySQL 5.7+（尤其 8.0+）中，部分系统表（如 mysql.role_edges、mysql.tables_priv）也启用独立表空间（innodb_file_per_table=ON），只要对应 .ibd 文件存在且未损坏，就能手动重关联。操作前确保：
- 已停写：
SET GLOBAL read_only = ON;+FLUSH TABLES WITH READ LOCK; - 备份整个
mysql数据库目录（尤其是mysql/下所有.ibd和.sdi文件） - 确认目标表结构未变更过（如未升级后跳过
mysql_upgrade）；否则需先从同版本干净实例导出CREATE TABLE语句
以修复 mysql.tables_priv 为例：
ALTER TABLE mysql.tables_priv DISCARD TABLESPACE; -- 确保 mysql/tables_priv.ibd 权限正确（属主 mysql，640） ALTER TABLE mysql.tables_priv IMPORT TABLESPACE;
成功后立即测试 SELECT COUNT(*) FROM mysql.tables_priv;。失败则说明 .ibd 文件实际已损坏，需换路径。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
重建 mysql 系统库（最后手段）
当多个系统表元数据全乱，或 ibdata1 中的数据字典页损坏（表现为 INFORMATION_SCHEMA 完全空、mysql.user 查不到用户），唯一可靠方式是初始化新系统库并迁移权限数据：
- 停止 MySQL，备份原
mysql/目录（保留user.MYD/user.MYI若有 MyISAM 表，或user.ibd+ 对应.sdi） - 用同版本 MySQL 执行
mysqld --initialize-insecure --datadir=/path/to/newdata，生成全新mysql库 - 启动新实例，将原
mysql.user、mysql.db等表数据导出（需先用CREATE TABLE重建空表结构） - 导入后执行
FLUSH PRIVILEGES;，并逐个校验SELECT和连接权限
注意：--initialize-insecure 不生成 root 密码，避免因密码哈希格式不兼容导致登录失败；若原库启用了 caching_sha2_password 插件，新实例必须加载相同插件再导入用户数据。
为什么不能直接复制 ibdata1 或跳过校验启动
ibdata1 是 InnoDB 共享表空间，包含数据字典、undo 日志、回滚段等核心元数据，它和 .ibd 文件之间有严格的 LSN（日志序列号）与 space_id 关联。强行替换或忽略校验（如设 innodb_force_recovery=6 后写入）会导致：
- 后续任何 DDL（如
ALTER TABLE）触发崩溃，因为字典缓存与物理页不一致 - 主从复制中断，GTID 事务无法解析，
SHOW SLAVE STATUS报Relay log read failure - 即使临时启动成功，
mysqldump导出的 SQL 在其他实例上执行会报Unknown table engine 'InnoDB'
真正棘手的从来不是“找不到数据”，而是“数据库自己不敢信自己的元数据”。修复动作越激进，后续一致性验证成本越高——宁可花 2 小时导出再重建，也不要赌 innodb_force_recovery=5 能绕过字典校验。
