数据传输前必须确保源库和目标库连接均测试成功，否则库列表为空；需区分本地（127.0.0.1）与远程（真实IP）地址，授权远程访问并设置保活、字符集一致等关键配置。
数据传输前必须确保两个连接都“测试成功”
很多人卡在第一步：点了“数据传输”却找不到源库或目标库，或者点开后列表为空。根本原因不是功能坏了，而是其中一个连接根本没通——navicat不会主动报错提示“连接失败”，只默默不加载库列表。
务必对远程和本地两个连接分别右键 → “测试连接”，看到绿色“连接成功”弹窗才算过关。常见失败点包括：
-
localhost误填为远程库地址（本地库应填127.0.0.1或localhost，且确认本地 MySQL 服务已启动，可通过services.msc查看MySQL80是否运行） - 远程库用了
127.0.0.1或localhost，但 Navicat 客户端不在数据库服务器本机上（必须填真实 IP，如172.26.100.145） - 远程 MySQL 用户未授权外网访问，
host字段仍是localhost，需改为%或指定 IP，并执行FLUSH PRIVILEGES;
“数据传输”窗口里最容易搞反的三处
界面看着简单，但源/目标一旦颠倒，轻则空跑、重则清空本地库。尤其当两个连接名都叫“test_db”或“prod”时，极易视觉混淆。
操作时盯紧这三项：
- 左上角“源”下拉框选的是远程连接（如
mysql-prod-remote），不是本地那个 - “源数据库”下拉菜单必须手动展开并点选，不能依赖默认值；同理，“目标数据库”要明确选中你本地新建好的库（如
local_backup），而非连接根节点 - 表列表右侧有“全选/取消全选”，但默认不勾选任何表——必须手动勾一个以上，否则点击“下一步”会静默跳过，无报错无日志
为什么传输中途断连？保活设置必须改
数据传输本质是长连接批量读写，若中间网络设备（如企业防火墙、云厂商 SLB）在 60 秒内没收到 TCP 包，就会单方面断开连接。Navicat 默认不发保活包，导致大表传输到一半突然中断，且错误提示常是模糊的 Lost connection to MySQL server during query。
解决方法不是重试，而是提前加固连接：
- 对远程连接，右键 → “编辑连接” → 切换到“高级”选项卡
- 勾选
保持连接活跃 - 将
每隔(秒)发送一个ping包设为60（不可大于 300，否则仍可能被回收） - 务必取消勾选
仅当有查询时发送ping，否则空闲阶段照样断连
注意：该设置只作用于当前连接，本地连接无需开启（除非你也用它跑长时间查询）。
结构不一致时传输会静默失败或字段乱码
Navicat 的“数据传输”默认同步结构+数据，但如果远程库用 utf8mb4_unicode_ci，而本地库建库时没指定字符集，就可能变成 latin1_swedish_ci，结果是中文变问号、emoji 存成空格，且过程无警告。
预防方式只有两条硬规则：
- 本地目标库必须提前创建，且显式指定字符集与排序规则，例如执行：
CREATE DATABASE `local_backup` CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
- 传输前在“高级”选项里点开“选项”，确认
字符集下拉框设为utf8mb4（不是默认的utf8），并勾选忽略外键检查和禁用唯一键检查，避免因索引冲突中断
真正麻烦的不是传输失败，而是传完才发现时间字段时区偏移、tinyint(1) 被转成布尔、自增 ID 重复——这些都不会报错，只能靠比对行数和抽样查数据。
