mysql 8.0系统库不能直接拷贝mysql/目录，因其表已完全迁入innodb数据字典，元数据与ibdata1、mysql.ibd、事务日志及系统表空间id强绑定；单独拷贝仅保留结构文件而缺失底层一致性校验要素，导致启动时因lsn不匹配、space id错位或路径越界等硬性校验失败。
直接拷贝旧 Data 目录到新 MySQL 实例几乎必然失败，核心原因是 ibdata1 和 .ibd 文件之间存在强绑定的元数据一致性，而新实例自带的系统表空间与旧文件不匹配。必须按物理迁移逻辑重置整个数据目录，不能只换库文件夹。
为什么只复制数据库子目录会报 Error 1812
MySQL 启动时会校验每个 .ibd 文件的 space_id 是否在 ibdata1 的数据字典中注册。只复制 mydb/ 这类业务目录，但保留新实例的 ibdata1，会导致 InnoDB 找不到对应表空间定义，于是抛出 Error 1812: Tablespace is missing for table xxx。
-
ibdata1不是“可选文件”，它是 InnoDB 系统表空间，存有所有表的内部 ID、列定义、外键约束等元数据 -
.ibd是独立表空间，只存数据页和索引页，不包含表结构或字典信息 - 即使版本相同，两个实例的
ibdata1初始内容也不同，无法混用
必须完整替换 Data 目录并清理残留
恢复动作不是“导入某个库”，而是“让新实例完全接管旧实例的全部物理状态”。这要求清空目标 Data 目录后，一次性塞入旧环境的全部内容。
- 停止新实例服务（
net stop MySQL80或systemctl stop mysqld） - 备份原
Data目录（哪怕只是重命名成Data.bak），再彻底清空该文件夹 - 把旧硬盘上的整个
Data文件夹内容（含ibdata1、ib_logfile*、mysql.ibd、undo_*、#innodb_redo/和所有业务库子目录）全部复制过去 - Windows 下确保
NETWORK SERVICE或对应服务账户对Data目录有“完全控制”权限；Linux 下执行chown -R mysql:mysql /var/lib/mysql
版本不一致时的 fallback 路径：innodb_force_recovery + mysqldump
若新旧 MySQL 大版本不同（如旧是 5.7，新装了 8.0），直接替换 Data 会启动失败。此时应放弃物理迁移，改走逻辑导出：
- 在旧环境或能挂载旧盘的机器上，用原版本 MySQL 启动，并在
my.cnf中临时加innodb_force_recovery = 1 - 逐级尝试 1→6（仅当 1 启动失败时才试 2，以此类推），直到能启动并访问表
- 立即执行
mysqldump --all-databases --single-transaction > full.sql导出 - 在新版本实例中创建空库，再用
mysql 导入（注意字符集、SQL mode 兼容性）
权限库（mysql schema）损坏时的特殊处理
如果旧 Data 中的 mysql.ibd 损坏，即使其他库数据完好，新实例也可能因无法加载用户权限而拒绝连接。此时不能跳过 mysql 目录，但可尝试：
- 先用新实例初始化一个干净的
mysql目录（启动一次空实例再停掉） - 只替换其中的
mysql.ibd为旧文件，保留新生成的mysql.frm（MySQL 8.0+ 已弃用 .frm，此步仅适用于 5.7） - 更稳妥的做法是：先用
mysqld --initialize-insecure初始化权限库，再用mysql_upgrade（MySQL 5.7）或mysqld --upgrade=FORCE（8.0+）强制重建系统表
真正关键的不是“拷得全不全”，而是“是否让 ibdata1 和所有 .ibd 在同一套运行时上下文中被首次加载”。任何跳过系统表空间、只换业务库的尝试，本质都是在对抗 InnoDB 的数据字典机制。
