不能直接迁移回自建mysql，因aurora在存储层、binlog格式、系统表及sql行为上存在隐性差异；mysqldump需禁用扩展特性并清理专属注释；xtrabackup不支持aurora物理备份；校验须用pt-table-checksum和统一checksum调用；务必同步时区与sql mode。
不能直接“迁移回”自建 MySQL——Aurora 的存储层、binlog 格式、内部系统表和部分 SQL 行为与标准 MySQL 存在隐性差异，盲目还原会导致主从同步中断、数据不一致或启动失败。
为什么 mysqldump 导出再导入会出问题？
Aurora 默认启用 aurora_lab_mode（尤其在 3.x 版本），其 binlog event 类型、GTID 实现、INFORMATION_SCHEMA 视图字段（如 INNODB_METRICS）与社区版 MySQL 不兼容；导出时若未显式禁用扩展特性，mysqldump 可能包含 Aurora 私有注释或不可识别的语法（例如 /*!50718 SET SESSION aurora_lab_mode=OFF */），导致目标 MySQL 解析失败。
- 导出时必须加
--skip-extended-insert和--set-gtid-purged=OFF，否则大表导入易卡死或 GTID 冲突 - 务必检查并手动清理 dump 文件中所有
/*!...*/形式的 Aurora 专属提示（如/*!50718 ... */） -
SHOW CREATE TABLE输出里若含ROW_FORMAT=COMPRESSED或KEY_BLOCK_SIZE，需改为ROW_FORMAT=DYNAMIC，否则 MySQL 8.0+ 会报错
用 Percona XtraBackup 做物理迁移要注意什么？
Percona XtraBackup 无法直接备份 Aurora 实例——Aurora 不暴露底层 InnoDB 文件系统，xtrabackup --backup 会报 Failed to connect to MySQL server 或 Cannot open /var/lib/mysql/ibdata1。你只能从 Aurora 的只读副本（如果开启过）或通过快照导出逻辑备份，再转成物理格式。
- 唯一可行路径：先用
mysqldump --single-transaction --routines --triggers --events导出全量，再用mysqlpump或mydumper分卷加速导入 - 若源 Aurora 开启了
binlog_format=STATEMENT，且业务含函数/临时表，必须改回ROW后再导出，否则mysqldump生成的语句在自建 MySQL 上执行会跳过某些变更 - 导入前，在目标 MySQL 执行
SET GLOBAL innodb_file_per_table=ON;，避免后续 DDL 失败
如何验证迁移后数据一致性？
不能只比行数——Aurora 的 SELECT COUNT(*) 在大表上可能返回估算值（尤其开启 innodb_stats_persistent 且统计信息未刷新），而自建 MySQL 返回精确值，造成误判。
- 用
pt-table-checksum（配合--replicate表）校验，但需先在目标 MySQL 创建复制用户，并确保网络连通、端口开放 - 对关键表，运行
CHECKSUM TABLE t1;对比两边结果，注意 Aurora 的 checksum 结果默认带/* !AURORA */注释，需用SELECT CHECKSUM_TABLE('t1', 'CRC32');统一调用方式 - 业务低峰期做一次
SELECT ... FOR UPDATE+UPDATE链路压测，确认锁行为、死锁日志格式、事务可见性是否一致
最常被忽略的是时区和 SQL mode：Aurora 默认 time_zone='+00:00' 且 sql_mode 包含 STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，而很多自建 MySQL 仍用宽松模式。不统一会导致时间字段截断、隐式类型转换异常，这类问题上线后才暴露，排查成本极高。
