不能直接用物理备份还原到MySQL 8.4，因为物理备份要求源目标的innodb_page_size、字符集校验规则、数据字典格式完全一致，而8.4引入新系统表结构和元数据加载逻辑，导致ibd文件可能被拒绝识别或查询时崩溃。
能迁，但必须用 mysqldump 且避开 GTID、XA 和默认认证插件这三类坑。
为什么不能直接用物理备份（cp / xtrabackup）还原到 8.4？
物理备份本质是二进制拷贝，要求源和目标的 innodb_page_size、字符集校验规则、数据字典格式完全一致。MySQL 8.0 到 8.4 虽属同大版本，但 8.4 引入了新的系统表结构、重写了部分元数据加载逻辑，ibd 文件可能被拒绝识别——常见报错如：Tablespace is missing for table xxx 或 InnoDB: Operating system error number 2 in a file operation。更隐蔽的是：若原表含降序索引、隐藏主键或 8.4 新增的函数索引，8.0 的 ibd 在 8.4 实例中即使挂载成功，也可能在查询时崩溃。
mysqldump 导出时必须关闭 --set-gtid-purged 和 --single-transaction 吗？
不是“必须关闭”，而是要按场景选配：
- 如果源库已启用 GTID（
gtid_mode = ON），导出时必须加--set-gtid-purged=OFF，否则导入时会触发ERROR 3546 (HY000): Cannot use SET GTID_PURGED with sql_log_bin = ON； -
--single-transaction可以保留（推荐），它能保证一致性快照，但前提是所有表都用 InnoDB 引擎；若混有 MyISAM 表，该选项无效，需改用--lock-all-tables； - 对含生成列、检查约束、全文索引的表，额外加
--skip-triggers --skip-routines，避免导出的触发器/存储过程因语法变更在 8.4 中报错。
导入到 MySQL 8.4 时最常卡在哪几个环节？
导入失败往往不是 SQL 语法问题，而是环境级兼容性断点：
- 用户认证插件不匹配：8.4 默认禁用
mysql_native_password，如果 dump 文件里含CREATE USER ... IDENTIFIED WITH mysql_native_password，导入会报错；解决方法是在目标实例启动前，在my.cnf的[mysqld]段落加mysql_native_password=ON； - 外键依赖顺序错误：直接
mysql -u root -p db_name 容易因外键未建好就插入数据而失败；正确做法是先只导入结构（<code>mysqldump --no-data），再临时关掉外键检查（SET FOREIGN_KEY_CHECKS=0;），最后导入数据； - 字符集声明冲突：dump 文件头若带
DEFAULT CHARSET=latin1，而目标库默认是utf8mb4，可能导致字段长度计算异常；建议导出时显式指定--default-character-set=utf8mb4，并确保目标库collation_server和character_set_server与之匹配。
迁移后必须立刻验证的三个动作
别只查行数是否一致——那掩盖不了结构或逻辑错误：
- 执行
XA RECOVER;：确认没有残留的分布式事务，否则升级后的崩溃恢复可能失败； - 运行
SELECT * FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE '%your_db%';：核对所有表空间是否正常加载，尤其关注STATE字段是否为active； - 对含 JSON 字段的表，执行一条
SELECT JSON_VALID(your_json_col) FROM your_table LIMIT 10;：8.0 到 8.4 对 JSON 解析更严格，某些宽松格式在 8.0 可存，在 8.4 查询时会报Invalid JSON text。
真正麻烦的从来不是 dump 和 source，而是那些没写在文档里的隐式依赖：XA 状态、GTID 位点、认证插件开关、甚至 sql_mode 的细微差异。每一步都得盯着错误日志，而不是只看 “Query OK”。
