必须加--compatible=mysql57和--default-character-set=utf8mb4导出，否则导入会因排序规则、零日期、JSON语法等报错；XtraBackup不可跨主版本使用，5.7备份须先恢复到5.7实例再逻辑导出。
不能直接用 mysqldump 生成的 SQL 文件原样导入 MySQL 8.0，也不能用 XtraBackup 5.7 备份集启动 8.0 实例——两者都会失败，且失败点往往在恢复后才暴露。
mysqldump 导出时必须加 --compatible=mysql57
即使你在 MySQL 8.0 上执行 mysqldump，只要目标是恢复到 5.7 或兼容 5.7 的环境（比如从 5.7 迁移过来），就必须强制降级语法输出。否则会遇到：
-
ERROR 1067 (42000): Invalid default value for 'created_at'：8.0 默认拒绝'0000-00-00'类零日期，而 5.7 备份里大量存在 -
Unknown collation: 'utf8mb4_0900_ai_ci'：该排序规则 5.7 完全不认识，导入直接中断 - 字段被静默截断：比如
VARCHAR(255)存了超长 emoji，5.7 下能存，8.0 严格校验后丢数据
正确命令示例（在任意版本 MySQL 上运行）：
mysqldump -u root -p --all-databases \ --compatible=mysql57 \ --default-character-set=utf8mb4 \ --skip-set-charset \ --skip-extended-insert \ --set-gtid-purged=OFF > backup_57.sql
注意：--skip-set-charset 防止导出文件里写死 SET NAMES utf8（8.0 已不推荐 utf8 别名）；--skip-extended-insert 方便后续手动替换 collation 或调试单条语句。
XtraBackup 物理备份不可跨主版本使用
xtrabackup 备份不是“拷贝完就能用”的快照，它强依赖 MySQL 主版本的 InnoDB 内部结构。MySQL 5.7 和 8.0 的系统表定义、redo log 格式、数据字典布局都不同。
- 用
xtrabackup 2.4.x备份的 5.7 数据，无法 用mysqld --datadir直接启动 MySQL 8.0 - 强行复制文件并启动，大概率报错：
Failed to initialize DD tables或Tablespace is missing - 就算侥幸启动，
mysql.user等系统表结构错位，权限体系立即失效
唯一安全路径：把 XtraBackup 5.7 备份先恢复到一台临时 5.7 实例，再用 mysqldump --compatible=mysql57 逻辑导出，最后导入 8.0。
恢复前必须检查并清理 5.7 备份中的危险内容
很多 5.7 备份里混着不该导出的东西，直接导入 8.0 会污染系统表或触发硬性限制：
- 避免导出
mysql系统库：mysqldump --all-databases默认包含它，但 8.0 的mysql.user表字段已从password改为authentication_string，字段数也不一致 - MyISAM 表要特别小心：5.7 中可能有用户 MyISAM 表，但若备份里意外含
mysql.db等系统 MyISAM 表，8.0 拒绝加载（系统表强制 InnoDB） - 检查是否有保留字命名对象：比如叫
rank、json、group的库/表名，8.0 将其列为关键字，建表会失败
建议操作顺序：
- 先用
grep -n "CREATE DATABASE.*mysql\|CREATE TABLE.*mysql\." backup_57.sql找出所有系统库相关行 - 用
sed -i '/^CREATE DATABASE `mysql`/,/^;/d' backup_57.sql删除整段（注意分号位置） - 导入前在 8.0 上执行
SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME IN ('mysql', 'information_schema', 'performance_schema');确认没动系统库
导入后必须验证三类关键行为变更
即使 SQL 成功执行，业务也可能因隐式行为变化而异常，这些不会报错，但结果已错：
-
GROUP BY不再隐式排序：5.7 下SELECT a,b FROM t GROUP BY a可能返回有序结果，8.0 下完全随机，应用层若依赖此行为会分页错乱 -
ORDER BY对 NULL 处理更严格：8.0 默认NULLS LAST，5.7 是NULLS FIRST，涉及统计报表时数值对不上 - 隐式类型转换收紧：比如
WHERE id = '123abc'在 5.7 返回id=123行，8.0 直接转成0导致无结果
最易被忽略的是字符集自动升级链：5.7 备份里若没显式指定 COLLATE，8.0 会按新默认 utf8mb4_0900_ai_ci 创建表——但老客户端连接未设 collation_server，读写过程就可能乱码。务必在导入前确认 my.cnf 中已设 collation_server = utf8mb4_general_ci（或与业务兼容的旧 collation）。
