迁移失败主因是权限不足或连接不通，需用实际账号测试：源库需SELECT和LOCK TABLES，目标库需CREATE、INSERT、INDEX；还需检查bind-address、防火墙及云数据库公网/SSH配置。
确认源库和目标库的连接与权限是否到位
迁移失败最常见的原因是账号没权限或连不通，不是 Navicat 有问题。必须用实际迁移账号测试两个连接：源库要能 SELECT 和 LOCK TABLES，目标库至少要有 CREATE、INSERT、INDEX 权限。别图省事直接用 root 测试完就切回普通账号——Navicat 不会自动帮你降权，权限缺失会在传输中途报错，比如 ERROR 1142: CREATE command denied 或 Access denied for INSERT。
局域网或云环境还要额外检查：
- 源 MySQL 是否绑定了 127.0.0.1（需改 bind-address = 0.0.0.0）
- 防火墙是否放行了 3306（Windows 防火墙/云安全组）
- 云数据库是否开启公网访问或配置了 SSH 隧道（Navicat 的 SSH 选项卡里填的是跳板机凭证，不是数据库账号）
用 Data Transfer 而不是导出 SQL 文件再导入
小体量（比如 .sql 再运行，既多一步又容易漏掉外键约束或自增起始值。Navicat 的 Data Transfer 功能在内存中直传，自动处理依赖顺序、字符集转换、时间戳默认值等细节。
操作时注意三点：
- 在向导第二步「选择对象」页，只勾选真正要迁的表，避开日志表、临时表（如 tmp_*、log_*）
- 进入「高级模式」后，把「每批次的行数」设为 10000（默认是单事务全量提交，小库没问题，但万一中断就得重来）
- 如果目标库已存在同名表，勾选「删除并重建目标表」而非「追加数据」，避免主键冲突或重复记录
迁移前强制比对字符集和排序规则
即使都是 MySQL，utf8mb4 字段在源库用 utf8mb4_general_ci，目标库用了 utf8mb4_0900_ai_ci，也可能导致中文检索异常或唯一索引失效。这不是 Navicat 的锅，但它不会主动警告。
执行迁移前，在两边库分别运行：
SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db_name';
如果结果不一致，就在目标库创建库时显式指定：
CREATE DATABASE target_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
另外，Navicat 默认不迁移 DEFINER 属性，存储过程或视图里带 DEFINER=`user`@`host` 的，迁过去可能报 ERROR 1449: The user specified as a definer does not exist。小体量库建议手动删掉导出 SQL 中的 DEFINER 行，或在 Navicat 高级设置里勾选「忽略 DEFINER」（该选项在「高级模式 → 表 → 选项」里）
验证迁移结果不能只看行数
Navicat 传输完成后显示「成功」，不代表数据完全一致。小体量库验证快，别跳过这步：
- 对每个表执行：SELECT COUNT(*) FROM table_name; 比对源和目标
- 抽查关键字段的最小/最大值，比如时间字段：SELECT MIN(created_at), MAX(created_at) FROM orders;
- 如果有唯一索引或主键，跑一次 CHECK TABLE table_name; 确认无损坏
- 最容易被忽略的是 TIMESTAMP 字段：MySQL 5.6+ 默认启用 explicit_defaults_for_timestamp，旧库没开的话，迁移后可能所有 NULL 值被转成当前时间——得在目标库执行 SET sql_mode = 'NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'; 后再查
