最可控的导入方式是 mysqldump + mysql 客户端：禁用 --all-databases，导入前执行 set autocommit = 0; set unique_checks = 0; 调大超时 set session wait_timeout = 28800; interactive_timeout = 28800; 并使用 --max-allowed-packet=1073741824。
直接用 mysqldump + mysql 客户端导入是最可控、最常被验证的方式，适合中小规模（innodb_page_size），要么依赖网络和权限配置（如 AWS DMS），容易卡在第一步。
确认本地 MySQL 和 Aurora MySQL 版本兼容性
不匹配会导致导入失败或隐性数据异常，比如函数行为差异、默认字符集不同、JSON 字段解析错误等。
- Aurora MySQL 3.x（基于 MySQL 8.0）不兼容 MySQL 5.6 或更早版本导出的
mysqldump文件（尤其含CREATE TABLE ... ENCRYPTION='Y'或新权限语法） - 推荐做法：本地 MySQL 版本 ≤ 目标 Aurora MySQL 版本；若本地是 5.7，目标选 Aurora MySQL 2.10+（兼容 MySQL 5.7）更稳妥
- 检查命令：
SELECT VERSION();（本地）和SELECT @@aurora_version;（Aurora）
用 mysqldump 导出时绕过常见陷阱
mysqldump 默认行为在 Aurora 上经常触发权限、字符集或 GTID 冲突，必须加关键参数。
- 务必加
--set-gtid-purged=OFF：Aurora 不支持手动设置 GTID，否则报错ERROR 1840 (HY000) - 加
--skip-triggers --skip-routines --skip-events：避免因 DEFINER 权限缺失导致导入中断（Aurora 默认禁用自定义 DEFINER） - 显式指定字符集：
--default-character-set=utf8mb4，并确保目标 Aurora 参数组中character_set_server和collation_server一致 - 大表建议分库导出：
mysqldump -u user -p --databases db1 db2 > dump.sql，别用--all-databases（会导出mysql系统库，Aurora 禁止写入）
导入到 Aurora 前必须关闭 autocommit 并调大超时
默认连接下批量导入极易因单语句超时或事务过大而中断，且 Aurora 对长事务更敏感。
- 连接后立即执行：
SET autocommit = 0;和SET unique_checks = 0;（导入后再设回 1） - 导入前调大两个关键超时：
SET SESSION wait_timeout = 28800;，SET SESSION interactive_timeout = 28800; - 用
mysql客户端时加选项：mysql -h your-aurora-endpoint -u admin -p --max-allowed-packet=1073741824 - 别用 MySQL Workbench 的“Table Data Import Wizard”——它会把大文件切片成低效小事务，反而拖慢进度
验证是否连到写入器实例再导入
向只读副本（reader）执行写操作会直接报错 ERROR 1792 (HY000): Cannot execute statement in a READ ONLY transaction，但错误信息不直观，容易误判为权限问题。
- 导入前务必确认连接的是写入器：
SHOW GLOBAL VARIABLES LIKE 'innodb_read_only';返回OFF才对 - 如果集群启用了 Aurora Serverless v2，注意其 endpoint 可能动态切换角色，建议用集群写入器专属 endpoint（形如
mycluster.cluster-xxxxxxxxxx.us-east-1.rds.amazonaws.com）而非 reader endpoint - 应用代码里硬编码 endpoint 时，别混淆
cluster（写入器）、cluster-ro（只读）和instance（单节点）三类地址
真正麻烦的不是导出或导入命令本身，而是字符集隐式转换、外键约束顺序、时区设置（time_zone 参数不一致会让 DATETIME 字段偏移）、以及 Aurora 自动添加的隐藏列（如 _rowid）对旧应用逻辑的影响——这些都不会在 mysqldump 过程中报错，却可能让上线后查询结果异常。迁移后至少跑一遍核心业务路径的 SELECT + JOIN 验证。
