大多数情况下能，但必须验证--set-gtid-purged和--skip-lock-tables的行为变化；gtid默认开启更严格，非gtid实例需显式加--set-gtid-purged=off，否则恢复失败。
MySQL 升级后 mysqldump 备份脚本还能直接用吗
大多数情况下能，但必须验证 --set-gtid-purged 和 --skip-lock-tables 的行为变化。MySQL 5.7 升级到 8.0 后，GTID 默认开启且更严格，mysqldump --set-gtid-purged=auto 在非 GTID 实例中可能报错 ERROR 1238 (HY000): Variable 'gtid_mode' is a read only variable；若升级前没开 GTID，备份时应显式加 --set-gtid-purged=OFF，否则 dump 文件头部会插入无效的 SET @@GLOBAL.GTID_PURGED 语句，导致恢复失败。
- 检查当前实例是否启用 GTID：
SELECT @@gtid_mode;，结果为ON才可安全使用--set-gtid-purged=AUTO - 跨大版本迁移（如 5.6→8.0）时，
mysqldump命令本身建议用目标版本的客户端，避免字符集或权限语法兼容问题 - 若备份含
DEFINER子句的视图或存储过程，升级后用户权限模型变更（如mysql.session系统账户），恢复时可能报ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist，需提前用--skip-definer或手动替换
Percona XtraBackup 升级后能否继续用于物理备份
不能直接沿用旧版本。XtraBackup 8.0 只支持 MySQL 8.0 及 Percona Server 8.0，与 MySQL 5.7 不兼容；同样，XtraBackup 2.4 最高只支持 MySQL 5.7。升级 MySQL 前必须同步升级 XtraBackup，并注意 xtrabackup 二进制文件路径、配置项名变化（如 --defaults-file 仍可用，但 --slave-info 在 8.0 中已改名为 --source-info）。
- MySQL 8.0 使用了新的数据字典表（存于
mysql.ibd），XtraBackup 2.4 无法识别，执行backup会卡在Starting to parse ibdata files...或报Unknown redo log format -
xtrabackup --prepare阶段若提示InnoDB: Unsupported redo log format，说明 XtraBackup 版本太低，必须换用 8.0+ 版本 - 备份时若启用了 MySQL 8.0 的原子 DDL（默认开启），XtraBackup 8.0 会自动处理，但恢复后需确认
mysql.innodb_ddl_log表为空，否则说明有未完成的 DDL 操作
升级后 binlog 备份和基于位点的恢复还可靠吗
不可靠，位点（File/Position）在 MySQL 8.0 中已不推荐依赖。8.0 默认启用 GTID，且 binlog 事件格式从 STATEMENT 改为 ROW（尤其涉及 JSON 或生成列时），SHOW MASTER STATUS 返回的 Position 值不再具备跨实例一致性——同一事务在不同从库上可能产生不同位点值。强行用旧脚本解析 mysql-bin.000001 + 位置号做 PITR，极易跳过或重复执行事务。
- 升级后应立即切换为 GTID 模式恢复：
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;，备份脚本中记录SELECT BINLOG_GTID_POS('mysql-bin.000001', 12345);替代传统位点 - binlog 保留策略要重设：
expire_logs_days已被弃用，改用binlog_expire_logs_seconds（单位秒），例如设为 604800 表示保留 7 天 - 若仍需解析 binlog（如审计或补数），
mysqlbinlog --base64-output=DECODE-ROWS -v输出中，###开头的行才是真实变更，旧脚本若正则匹配UPDATE.*WHERE可能漏掉 ROW 格式内容
备份文件恢复到新版本 MySQL 时最常踩的坑
不是编码或权限问题，而是系统表结构不兼容。MySQL 8.0 的 mysql 库是 InnoDB 引擎且含隐藏字段（如 account_locked），而 5.7 的 mysqldump 备份中 mysql.user 表结构不含这些字段，直接 source 会报 ERROR 1682 (HY000): Native table 'mysql'.'user' has the wrong structure。
- 不要用
mysqldump全库备份恢复系统库：mysql、performance_schema、information_schema必须由 MySQL 实例初始化生成，备份脚本中应排除它们：mysqldump --all-databases --ignore-table=mysql.user --ignore-table=mysql.db ... - 用户密码哈希方式变了：8.0 默认用
caching_sha2_password，若备份中含CREATE USER ... IDENTIFIED WITH mysql_native_password，恢复后连接会报Authentication plugin 'caching_sha2_password' cannot be loaded，需统一指定插件或升级客户端驱动 - 字符集相关参数如
collation_server在 8.0 中默认为utf8mb4_0900_ai_ci，若应用仍用utf8mb4_general_ci，备份恢复后查询可能因排序规则差异返回不同结果，建议在备份前执行SET NAMES utf8mb4 COLLATE utf8mb4_0900_ai_ci;再 dump
