应同步调高MySQL的wait_timeout、interactive_timeout、net_read_timeout和net_write_timeout四项参数，并在Navicat中启用“保持连接活跃”、取消“仅当有查询时发送ping”、关闭“自动断开空闲连接”，若走SSH隧道还需配置ClientAliveInterval和ServerAliveInterval，且同步中断后不支持断点续传。
为什么同步大表时总报“Connection reset by peer”
这不是网络抖动或数据库挂了，而是 mysql 服务端主动回收空闲连接——navicat 在解析元数据、校验约束、构建 insert 批次时可能几十秒不发新请求，触发 wait_timeout 或 interactive_timeout 断连。错误日志里看不到异常，show processlist 也查不到残留连接，但 navicat 界面卡在“正在传输…”后直接报错，就是典型表现。
必须同时调高 MySQL 的三个超时参数
只改 wait_timeout 不够，Navicat 建立的连接类型受驱动影响，常被归为交互式，所以两个 timeout 都得设；而大数据读写本身也可能超时，net_read_timeout 和 net_write_timeout 同样关键：
-
wait_timeout和interactive_timeout：建议统一设为86400（24 小时），避免重启失效可先用SET GLOBAL临时生效 -
net_read_timeout：设为600（10 分钟），防止大结果集读取中途断开 -
net_write_timeout：同样设为600，应对慢速网络或批量写入延迟 - 修改后必须重启 MySQL 服务，或确认动态设置已生效：
SELECT @@wait_timeout, @@interactive_timeout;
Navicat 连接配置里这两个选项不能只开一个
很多人只开了“保持连接活跃”，却漏掉关键开关，结果还是断：
- 必须勾选“保持连接活跃”，间隔设为
60秒（小于云厂商 NAT 超时，又不至于太频繁） - 必须取消勾选“仅当有查询时发送 ping”——同步过程中的解析、校验阶段没 query，不取消就等于没开保活
- 必须关闭“自动断开空闲连接”（部分版本叫
Disconnect when idle），否则 Navicat 自己会先发COM_QUIT，比服务端还早断 - 如果走 SSH 隧道，还要在本地 SSH 配置加
ServerAliveInterval 30，跳板机上配ClientAliveInterval 30，否则 MySQL 参数再大也没用
同步中断后不会续传，得靠人工分段控制
Navicat 的数据同步任务没有断点续传机制——中断后重跑，会从头开始，不是接着上次位置继续。这意味着：
- 别指望它自己记住“已同步到第 127894 行”，它只会全量重来
- 对超大表，应提前用
WHERE条件拆分（如按时间范围或 ID 区间），手动分批同步 - 导出时禁用“Commit every batch”，改用更大
Batch size（如 10000），减少事务往返和 SSL 握手开销 - 若用结构+数据同步，优先分开执行：先同步结构（快），再单独同步各张大表（可控）
