mysqldump导出的sql备份在mysql 8.4上恢复基本可行，但需手动处理字符集（必须utf8mb4）、权限、目标库预创建、max-allowed-packet等参数调大、bom头清除及外键约束关闭等关键兼容性问题。
mysqldump 导出的 SQL 备份，在 MySQL 8.4 上恢复基本可行，但必须手动处理几处关键兼容性断裂点——不是直接 mysql -u root -p 就能跑通。
<h3>为什么不能直接导入？</h3>
<p>MySQL 8.0 和 8.4 之间存在三类硬性不兼容项：认证插件默认变更、排序规则（collation）升级、部分系统视图定义差异。备份文件里若含 <code>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 <h3>外键和唯一约束导致导入卡住？</h3> <p>大库导入常卡在某条 INSERT，错误提示类似：</p> <pre class="brush:php;toolbar:false;">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 <p>或者更稳妥：登录进 <a style="color:#f60; text-decoration:underline;" title="mysql" href="https://m.php.cn/zt/15713.html" target="_blank">mysql</a> 客户端，先执行那两行 <code>SET</code>，再 <code>source backup.sql</code>。</p> 真正麻烦的从来不是“怎么导入”，而是“导入后哪些对象没生效”——比如存储过程里用了 8.0 已废弃的 <code>FOUND_ROWS()</code>，或事件调度器里写了已被移除的 <code>ON COMPLETION PRESERVE</code>。这些不会在导入时报错，但运行时才崩。务必在测试环境完整跑一遍业务 SQL 再上线。
