跨版本恢复必须用逻辑备份，因物理文件结构不兼容；MySQL、Oracle、HGDB等需用同版本导出工具（如mysqldump、expdp、pg_dump）生成SQL再重放，且须严格匹配版本并手动修正语法、字符集、ALGORITHM等。
跨版本恢复必须用逻辑备份，物理文件拷贝直接失效
mysql、oracle、瀚高（hgdb）等主流数据库跨大版本恢复时，直接复制数据文件、控制文件或归档日志，100%失败。这不是操作问题，而是底层结构已变——比如 mysql 8.0 的 mysql.user 表用 authentication_string 替代了 5.7 的 password 字段；oracle 19c 的控制文件格式不被 12c 识别；hgdb v9 的系统表新增字段会让 v8 解析报错。
所以“手动备份完整数据库”在跨版本场景下，唯一有效路径是：用源库版本的逻辑导出工具生成 SQL 或归档，再在目标库中重放。不是“能不能做”，而是“别无选择”。
- MySQL → 用
mysqldump（必须是源库同版本，如 5.7.35 导出，不能用 8.0 的 mysqldump 去 dump 5.7 库） - Oracle → 用
expdp（Data Pump），禁用VERSION=12.1等兼容参数时要格外小心，低版本 expdp 不支持高版本新对象 - HGDB/PostgreSQL 兼容体系 → 用
pg_dump，且必须匹配源库主版本号（V8.3 不能用 V9.0 的 pg_dump）
mysqldump 跨版本导出时，这几个参数决定成败
导出命令看着简单，但一个参数错，还原时就卡在第一行。尤其从 5.7 → 8.0 这类常见升级，--compatible 和 --skip-xxx 不是可选项，是保命开关。
-
--compatible=mysql40：强制降级语法（如去掉引号包裹的保留字），避免 8.0 严格模式报错 -
--skip-triggers --skip-routines --skip-events：触发器/存储过程/事件里若含 8.0 新函数（如JSON_EXTRACT），5.7 导出后在 8.0 导入会直接中断 -
--no-tablespaces：跳过表空间定义语句，因 8.0 默认启用innodb_file_per_table，而 5.7 可能未启用，混用导致表无法加载 - 绝对不要加
--set-gtid-purged=ON：GTID 在 5.7 和 8.0 实现机制不同，该参数在目标库开启 GTID 时会引发主从异常
示例安全导出（5.7 源库 → 8.0 目标库）：mysqldump -u root -p --compatible=mysql40 --skip-triggers --skip-routines --skip-events --no-tablespaces --single-transaction mydb > mydb_57.sql
导入前必须手动干预 dump 文件，自动导入大概率失败
即使导出参数全对，生成的 .sql 文件仍含目标库不认的语句。别指望 --force 参数兜底——它跳过错误但不修复语义，可能留下空表、缺失索引或乱码字段。
- 删掉所有
SET @@SESSION.SQL_LOG_BIN = 0;：8.0 默认禁止会话级关闭 binlog，执行即报错 - 替换字符集声明：
COLLATE=utf8mb4_0900_ai_ci改成COLLATE=utf8mb4_unicode_ci（5.7 不认识 0900 排序规则） - 检查并删除
CREATE DATABASE ... CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;这类语句，改用人工建库：CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 若 dump 含
ALTER TABLE ... ALGORITHM=INSTANT（8.0 新语法），需手动改为ALGORITHM=COPY或删掉整行（5.7 不支持 INSTANT）
验证方法：用 head -n 50 mydb_57.sql 扫一眼开头，重点看 CREATE DATABASE、SET、COLLATE 出现的位置。
Oracle/HGDB 跨版本恢复更刚性，没中间态可绕
Oracle 的 expdp 和 HGDB 的 pg_dump 对版本咬得比 MySQL 更死。Oracle 官方明确：12c 的 dump 文件无法被 11g impdp 读取；HGDB V9 的 pg_dump 输出，V8 的 pg_restore 直接拒绝解析——报错类似 unrecognized archive format 或 version mismatch。
- Oracle 唯一合规路径：在源库服务器上用源库版本的
expdp导出，传输到目标服务器后，用目标库同版本的impdp导入（注意：不是“同大版本”，是“同 $ORACLE_HOME/bin 下的二进制版本”） - HGDB 必须使用
pg_dump --format=plain（文本 SQL 格式），禁用--format=custom（二进制格式），因为后者带版本签名，跨主版本不可读 - 两者都严禁在 dump 前修改
init.ora或postgresql.conf中的兼容参数试图“欺骗”版本——配置不改变实际编目结构，只会让导入中途崩溃
真正省事的办法只有一个：在目标环境先升级数据库软件，再导入。想跳过这步，就得接受数据清洗、手工重建、部分功能弃用这些现实代价。
