MySQL 8.4如何恢复MySQL 8.0的备份

mysqldump导出的SQL备份在MySQL 8.4上恢复基本可行，但需手动处理字符集（必须utf8mb4）、权限、目标库预创建、max-allowed-packet等参数调大、BOM头清除及外键约束关闭等关键兼容性问题。

mysqldump 导出的 SQL 备份，在 MySQL 8.4 上恢复基本可行，但必须手动处理几处关键兼容性断裂点——不是直接 mysql -u root -p 就能跑通。

为什么不能直接导入？

MySQL 8.0 和 8.4 之间存在三类硬性不兼容项：认证插件默认变更、排序规则（collation）升级、部分系统视图定义差异。备份文件里若含 CREATE USER 或 CREATE DATABASE 语句，8.4 会直接报错退出，例如：

ERROR 1064 (42000) at line XXX: You have an error in your SQL syntax...

或更典型的：

ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement

导入前必须预处理 backup.sql

删掉所有 DROP DATABASE 和 CREATE DATABASE 行（除非你明确要覆盖目标库），用文本编辑器全局搜索删除，或用 sed -i '/^CREATE DATABASE|^DROP DATABASE/d' backup.sql 替换所有 utf8mb4_0900_ai_ci 为 utf8mb4_general_ci（仅当目标库是 8.0 备份、且你不想升级 collation 时；若想保持 8.4 默认行为，这步跳过，但需确保目标库已用 CREATE DATABASE ... COLLATE utf8mb4_0900_ai_ci 显式创建） 删掉或注释掉 CREATE USER 和 GRANT 相关块——8.4 默认用 caching_sha2_password，而 8.0 备份里多是 mysql_native_password，混在一起会触发插件不匹配错误 检查并删除 SET @@SESSION.SQL_LOG_BIN= 0; 这类语句（常见于带 --set-gtid-purged=ON 的导出），8.4 在非 super 权限下禁止该操作

目标库必须提前建好且字符集匹配

别指望备份文件里的 USE db_name 自动建库——它只切换上下文。你得手动执行：

CREATE DATABASE myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

注意：utf8mb4_0900_ai_ci 是 8.4 默认 collation，如果源库是 8.0（用的是 utf8mb4_general_ci），而你又没在预处理中替换，这里就必须用后者，否则表创建时会报 Unknown collation。

建库后，再导入：

mysql -u root -p myapp 

外键和唯一约束导致导入卡住？

大库导入常卡在某条 INSERT，错误提示类似：

ERROR 1062 (23000): Duplicate entry 'X' for key 'PRIMARY'

这不是数据重复，而是外键约束或唯一索引在导入中途被触发。解决方法是在导入命令前加开关：

mysql -u root -p -e "SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;" myapp && mysql -u root -p myapp 

或者更稳妥：登录进 mysql 客户端，先执行那两行 SET，再 source backup.sql。

真正麻烦的从来不是“怎么导入”，而是“导入后哪些对象没生效”——比如存储过程里用了 8.0 已废弃的 FOUND_ROWS()，或事件调度器里写了已被移除的 ON COMPLETION PRESERVE。这些不会在导入时报错，但运行时才崩。务必在测试环境完整跑一遍业务 SQL 再上线。