如何将MySQL 5.7的数据平滑迁移到MySQL 8.0版本中？-mysql教程-PHP中文网

mysql 5.7 备份不能直接导入 8.0，因系统表结构变更（password→authentication_string）、认证插件升级（caching_sha2_password）、字符集弃用（utf8mb3）等硬性冲突，须清理系统库、替换引擎与密码函数、调整sql_mode后导入。

如何将mysql 5.7的数据平滑迁移到mysql 8.0版本中？

不能靠 mysqldump --all-databases 直接导出再导入——这会把 5.7 的系统表、utf8mb3 字符集、MyISAM 引擎定义、PASSWORD() 函数等一并塞进 8.0，轻则乱码、连不上，重则启动失败、权限丢失。

为什么 mysqldump 导入在 MySQL 8.0 上大概率失败

看似只是“换版本”，但 5.7 和 8.0 在数据层有三处硬性不兼容：

mysql 系统库结构已重构：5.7 的 user 表含 password 字段，8.0 改为 authentication_string；直接导入会破坏权限系统
默认认证插件从 mysql_native_password 变为 caching_sha2_password，老驱动（如 PyMySQL Authentication plugin 'caching_sha2_password' cannot be loaded
utf8 实际是 utf8mb3，而 8.0 已弃用；导入时若没显式指定字符集，会触发隐式转换，中文字段索引失效、排序异常

必须用 mysqlsh 的 util.checkForServerUpgrade() 做前置扫描

这是 Oracle 官方唯一推荐的跨大版本兼容性检查工具，mysqlcheck 完全无效——它只校验表是否损坏，对语义级变更（如保留字 rank、NO_AUTO_CREATE_USER 移除）毫无感知。

执行前确认三点：

MySQL 5.7 实例正在运行，且 root 可通过 socket 连接（优先用 -S /tmp/mysql.sock，避免 DNS 或防火墙干扰）
使用与目标 8.0 版本一致的 mysql-shell（如升到 8.0.42，就得用 mysql-shell-8.0.42）

命令中必须指定 targetVersion 和输出格式，例如：

mysqlsh --uri root@localhost:3306 --sql -e "util.checkForServerUpgrade({targetVersion: '8.0.42', outputFormat: 'JSON'})" > upgrade_report.json

报告里 summary.overallStatus 必须是 "OK" 才能继续；若为 "ERROR"，需按 description 逐条处理，比如：Usage of utf8mb3 charset → 先 ALTER DATABASE ... CONVERT TO CHARACTER SET utf8mb4。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

in-place 升级时 mysqld 启动失败的三大硬坑

替换二进制后卡在 “Starting MySQL” 或日志里只有模糊的 unknown variable，大概率掉进以下任一陷阱：

my.cnf 里残留已废弃参数：query_cache_type、explicit_defaults_for_timestamp、log_warnings —— 必须删掉或注释
数据目录下存在孤立 .frm 文件（比如手动删过 .ibd 却没 DROP TABLE），mysqlcheck 会报错中止，得先清理或修复对应表
系统库 mysql 下有自定义表名与 8.0 新系统表冲突（如 roles、role_edges），启动时初始化失败，必须重命名或删掉

启动成功 ≠ 升级完成。首次用 8.0 的 mysqld 启动时，必须加 --upgrade=FORCE 显式触发数据字典升级（mysql_upgrade 工具在 8.0 中已被彻底弃用）。

升级后第一件事不是开业务，而是验证三组关键状态

服务进程起来只是第一步，以下三条命令缺一不可：

SELECT VERSION(), @@sql_mode; —— 确认版本是 8.0.x，且 ONLY_FULL_GROUP_BY 在列表中（否则 GROUP BY 行为突变）
SHOW VARIABLES LIKE 'default_authentication_plugin'; —— 若返回 caching_sha2_password 但应用驱动不支持，立刻建兼容用户：CREATE USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx';
SELECT * FROM performance_schema.replication_applier_status_by_coordinator; —— 如果开了复制，这里必须显示 APPLYING，否则 GTID 或 relay log 没续上，主从已不同步

最常被忽略的是：8.0 的 performance_schema 表结构和收集逻辑已重写，漏掉验证会导致监控指标全空，问题发生时才发现“什么都没报”。