跨架构mysql迁移唯一可靠路径是逻辑导出，因innodb二进制文件与字节序、内存对齐强绑定，物理拷贝必然失败；mydumper需在目标aarch64环境源码编译，mysql 5.7→8.0迁移必须跳过系统库导出并执行mysql_upgrade，字符集须显式统一为utf8mb4_0900_as_cs。
mydumper 在跨架构离线环境必须手动解决依赖链
直接 rpm -ivh 会失败，因为 aarch64 目标机无法运行 x86_64 的二进制包，哪怕只是 mydumper 工具本身。你不能在 CentOS7 x86_64 上编译出能跑在 KylinV10 aarch64 上的 mydumper —— 架构不匹配，交叉编译又极容易漏掉动态链接库。
正确做法是：在一台与目标环境完全一致的联网 aarch64 机器（比如另一台 KylinV10 或 RHEL8 aarch64）上，用源码编译 mydumper，并带上所有 runtime 依赖：
- 先装构建工具：
yum install -y gcc cmake make openssl-devel glib2-devel pcre2-devel - 下载源码：
git clone https://github.com/mydumper/mydumper.git && cd mydumper - 指定 MySQL 客户端头文件和库路径（KylinV10 默认用
mariadb-devel）：cmake -DWITH_MYSQL=ON -DMYSQL_CONFIG_EXECUTABLE=/usr/bin/mysql_config . -
make && sudo make install，生成的mydumper和mysqldumper二进制可直接拷贝到目标机
注意：mysql_config 必须来自目标系统（aarch64），否则链接时会混入 x86_64 符号；ldd ./mydumper 要确认所有 so 都能在目标机 /usr/lib64 或 /lib64 找到。
MySQL 5.7 → 8.0 迁移必须处理系统表与权限模型变更
MySQL 8.0 用 mysql.user 表替代了 5.7 的 mysql.db + mysql.tables_priv 等多张权限表，且默认启用 caching_sha2_password 认证插件。直接导入 5.7 的 mysqldump --all-databases 备份会导致权限失效甚至启动失败。
实操建议分两步走：
- 导出时不带系统库：
mysqldump -u root -p --single-transaction --routines --triggers --events --ignore-table=mysql.user --ignore-table=mysql.db --ignore-table=mysql.tables_priv --ignore-table=mysql.columns_priv --ignore-table=mysql.procs_priv --ignore-table=mysql.proxies_priv --databases your_db1 your_db2 > data.sql - 目标机初始化 MySQL 8.0 后，先执行
mysql_upgrade（不是可选步骤！），再导入业务库；用户权限需重建：CREATE USER 'xxx'@'%' IDENTIFIED WITH caching_sha2_password BY 'pwd'; GRANT ALL ON your_db1.* TO 'xxx'@'%';
别跳过 mysql_upgrade —— 它会重写系统表结构、更新数据字典，缺失它，SHOW DATABASES 可能看不到你刚导入的库。
字符集与排序规则不兼容会导致导入静默失败
CentOS7 默认 MySQL 5.7 使用 utf8mb4_general_ci，而 KylinV10 上 MySQL 8.0.42 默认是 utf8mb4_0900_as_cs（大小写敏感+口音敏感）。如果导出 SQL 里没显式声明 CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs，导入时会按目标库默认规则创建表，但已有数据可能因排序规则差异被截断或报错。
安全做法是统一显式指定：
- 导出时加参数：
--default-character-set=utf8mb4 --collation-server=utf8mb4_0900_as_cs - 导入前在目标库执行：
SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs; - 检查建表语句是否含
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_as_cs；若不含，用sed -i 's/ENGINE=InnoDB;/ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_as_cs;/g' data.sql批量补全
尤其注意：MySQL 8.0 对 utf8mb4_0900_as_cs 的索引长度限制更严（比如 TEXT 字段前缀索引最大 3072 字节），旧表结构可能需要调整。
物理迁移在跨架构场景下完全不可行
cp -r /var/lib/mysql /newpath 或 tar 打包 data 目录，在 x86_64 → aarch64 场景下必然失败。InnoDB 的 ibdata1、ib_logfile*、.ibd 文件都包含平台相关字节序和内存对齐信息，直接拷贝会导致 MySQL 8.0 启动时报 InnoDB: Database page corruption on disk or a failed file read 或直接拒绝加载。
唯一可行的“物理级”迁移方式是：
- 在源机用
mydumper --compress --threads=4 --chunk-filesize=50分块导出 - 在目标 aarch64 机用
mysqldump --skip-extended-insert生成单条 INSERT，避免大事务撑爆内存 - 导入时禁用唯一检查：
SET unique_checks=0; SET foreign_key_checks=0;，导入完成后再开
跨架构迁移没有捷径，逻辑导出是唯一可靠路径。别信“改 datadir 就能跑”的说法——那是同架构下的经验，不适用于 x86_64 和 aarch64 之间。
