MySQL 5.7 迁移至 8.0 连续踩坑实录｜6 个连锁报错完整排查方案

背景：老旧业务库从 MySQL5.7 迁移到 MySQL8.0，直接使用 mysqldump --all-databases 导出再导入，接连踩中视图、注释编码、GTID、系统表引擎一系列连锁坑，本文一次性汇总现象、根因、避坑方案，适合做跨版本迁移的运维同学直接收藏。

前置说明

MySQL5.7 校验宽松，大量历史脏数据、旧特性可以正常运行；MySQL8.0 在元数据校验、GTID 一致性、系统表引擎等方面做了强约束，很多在 5.7 正常的备份包，导入 8.0 直接中断。

不推荐跨版本迁移直接使用 --all-databases，这是绝大多数问题的源头。

报错 1：1356 无效视图

报错信息

mysqldump: Couldn't execute 'show create table `device_driver_car`': View 'greencar.device_driver_car' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)

根因

库内存在损坏视图，视图依赖的表、字段已经删除或者权限缺失，mysqldump 在读取视图定义时直接终止备份。

解决方案

1. 应急导出：增加 --force 参数，跳过损坏对象继续导出
2. 根治：登录源库，找到无效视图删除或者重建

-- 查找异常视图
SELECT TABLE_SCHEMA,TABLE_NAME FROM information_schema.VIEWS WHERE TABLE_SCHEMA='greencar';

报错 2：4088 字段注释包含非法 utf8mb3 字符

报错信息

ERROR 4088 (HY000) at line 3382: Comment for field 'db3_yc_core.audit_order.update_time' contains an invalid utf8mb3 character string: '\xB8\xFC\xD0'

根因

源头是 5.7 库里面字段注释写了 GBK/GB2312 中文字节，不是合法 UTF-8。 MySQL5.7 对注释编码无强校验，可以正常保存导出；MySQL8.0 对表 / 字段注释做严格 UTF 校验，哪怕库是 utf8mb4 也会拦截。

注意：业务数据本身没问题，只是注释里面藏了脏字节。

解决方案

1. 导出阶段直接规避：增加 --skip-comments，不导出表、字段注释（迁移首选）
2. 预处理 SQL：打开 SQL 文件，删除报错字段的 COMMENT 子句
3. 源头修复：源库执行 ALTER TABLE 重写注释，替换非法字节

❌ 误区：修改客户端连接字符集 --default-character-set=utf8mb4 无法修复，字节本身在 SQL 源码里就是非法的。

报错 3：1785 GTID 一致性冲突

报错信息

ERROR 1785 (HY000): Statement violates GTID consistency: Updates to non-transactional tables can only be done in either autocommitted statements or single-statement transactions, and never in the same statement as updates to transactional tables.

根因

GTID 开启状态下，同一个事务不能同时更新 InnoDB（事务表） + MyISAM（非事务表）。 --single-transaction 会把所有 DML 打包在 BEGIN;COMMIT; 事务块，一旦库内混合两种引擎，直接触发约束。

解决方案

1. 首选：导出命令去掉 --single-transaction，每条 DML 自动提交，不会打包在同一个事务 代价：MyISAM 表备份期间会锁表，务必业务低峰执行
2. 根治：把所有业务 MyISAM 表转为 InnoDB

SELECT CONCAT('ALTER TABLE `',TABLE_SCHEMA,'`.`',TABLE_NAME,'` ENGINE=InnoDB;') AS sql_text
FROM information_schema.TABLES
WHERE ENGINE='MyISAM'
AND TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema','sys');

报错 4：1229 变量仅支持 GLOBAL 级别设置

报错信息

ERROR 1229 (HY000): Variable 'enforce_gtid_consistency' is a GLOBAL variable and should be set with SET GLOBAL

根因

enforce_gtid_consistency 属于全局变量，不支持 session 会话级别修改，不能写 SET @@session.enforce_gtid_consistency = OFF;。 并且还有硬绑定规则：gtid_mode=ON 时，enforce_gtid_consistency 强制为 ON，无法单独关闭。

解决方案

尽量不要修改 GTID 全局参数来绕报错，优先调整导出脚本；如果是离线单机恢复必须修改 GTID，需要逐级切换。

报错 5：1788 GTID_MODE 不能跨阶跳转

报错信息

ERROR 1788 (HY000): The value of @@GLOBAL.GTID_MODE can only be changed one step at a time: OFF <-> OFF_PERMISSIVE <-> ON_PERMISSIVE <-> ON.

根因

gtid_mode 状态流转是链式的，不允许跳跃切换 流转顺序：ON ↔ ON_PERMISSIVE ↔ OFF_PERMISSIVE ↔ OFF ON 不能直接切换到 OFF_PERMISSIVE，必须一步一步降级。

完整降级顺序（仅单机离线恢复使用，主从集群严禁操作）

-- 降级
SET GLOBAL gtid_mode = ON_PERMISSIVE;
SET GLOBAL gtid_mode = OFF_PERMISSIVE;
SET GLOBAL enforce_gtid_consistency = OFF;

-- 导入完成后恢复
SET GLOBAL enforce_gtid_consistency = ON;
SET GLOBAL gtid_mode = ON_PERMISSIVE;
SET GLOBAL gtid_mode = ON;

⚠️ 风险提示：主从环境所有节点必须同步步进修改，极易造成 GTID 集合错乱、主从复制断裂。

报错 6：1726 MyISAM 不支持系统表 mysql.user

报错信息

ERROR 1726 (HY000): Storage engine 'MyISAM' does not support system tables. [mysql.user]

根因

MySQL5.7 的 mysql 系统库（user、db 等权限表）默认引擎是 MyISAM； MySQL8.0 强制所有系统字典表、权限表使用 InnoDB，禁止系统表使用 MyISAM。 如果使用 --all-databases，会连带导出 5.7 的 mysql 库，导入 8.0 直接报错。

额外大坑：5.7 和 8.0 的 mysql 库表结构、数据字典完全不同，就算修改引擎强行导入，也会直接破坏目标库权限系统。

解决方案

跨版本迁移严禁导入 mysql 系统库，业务库和账号权限分开导出：

1. 业务库导出，直接排除四大系统库：mysql、sys、information_schema、performance_schema
2. 账号权限单独导出授权语句，在目标 8.0 实例上重建账号，复用 8.0 原生 mysql 库

✅ 最终稳定导出命令（5.7→8.0 迁移专用，规避全部 6 个坑）

mysqldump -h127.0.0.1 -uroot -p \
--force \
--routines --triggers \
--skip-comments \
--ignore-database=mysql \
--ignore-database=sys \
--ignore-database=information_schema \
--ignore-database=performance_schema \
> business.sql

参数说明：

• --force：跳过损坏视图等异常对象
• --skip-comments：不导出注释，规避 4088 编码报错
• 移除 --single-transaction：规避 MyISAM+InnoDB 混合事务触发 1785 GTID 报错
• --ignore-database：排除系统库，规避 1726 系统表引擎报错

账号权限单独导出脚本（MySQL5.7）：

SELECT CONCAT('SHOW GRANTS FOR ''',user,'''@''',host,''';') FROM mysql.user;

📌 迁移规范总结

1. 5.7 迁移 8.0，放弃 --all-databases，业务库、权限分开迁移；
2. 历史库存在 MyISAM，优先在源库全部转为 InnoDB，是长期最稳妥方案；
3. GTID 相关全局参数改动风险极高，只在离线单机恢复场景临时使用，生产主从尽量不动；
4. 迁移前检查清单：无效视图、字段注释脏编码、MyISAM 引擎表、系统库导出；
5. 注释仅属于文档信息，跨版本迁移优先舍弃注释，业务稳定优先。

补充

这套坑非常有代表性，很多老系统迁移都会连续遇到，本质不是 MySQL8.0 的 bug，是 8.0 收紧了 5.7 时代宽松的兼容策略。备份导出策略优先做源头规避，而不是导入的时候不断修改数据库参数去适配脏备份包。