源库报“Connection reset by peer”时应先查wait_timeout和interactive_timeout；Navicat同步大数据量中断主因是MySQL服务端空闲超时主动断连，需同步调整两参数并关闭Navicat“自动断开空闲连接”选项。
源库报“Connection reset by peer”时先查 wait_timeout 和 interactive_timeout
navicat 同步大数据量时，源库主动断开连接，常见现象是日志里出现 connection reset by peer 或 navicat 报错 error 2013 (hy000): lost connection to mysql server during query。根本原因不是网络抖动，而是 mysql 服务端在空闲期主动关闭了连接——navicat 在读取大表过程中可能长时间没发新请求（比如解析中间结果、校验约束），触发了超时回收。
关键参数有两个：wait_timeout（非交互式连接超时，默认 28800 秒即 8 小时）和 interactive_timeout（交互式连接超时，默认也是 28800）。但 Navicat 建立的连接类型取决于驱动行为，实际常被归类为交互式连接，所以两个都得调。
- 登录源库执行：
SHOW VARIABLES LIKE '%timeout%';确认当前值 - 临时生效（重启后失效）：
SET GLOBAL wait_timeout = 28800; SET GLOBAL interactive_timeout = 28800;（若已较高，可先试 86400） - 永久生效：编辑 MySQL 配置文件（如
/etc/my.cnf或C:\ProgramData\MySQL\MySQL Server X.X\my.ini），在[mysqld]下添加：
wait_timeout = 86400 interactive_timeout = 86400
改完需重启 MySQL 服务，且注意该设置影响所有客户端连接，不要无限制拉高（比如设成 0 表示永不超时，不推荐）。
Navicat 连接配置里也要关掉“自动断开空闲连接”
即使源库 timeout 调高了，Navicat 自己也可能提前切断连接。它有个隐藏逻辑：如果连接空闲超过一定时间，会主动发 COM_QUIT 关闭连接，再同步时就变成“重连失败”而非“连接中被杀”。
这个行为由 Navicat 的连接保活机制控制，但默认的“保持连接活跃”只发 ping，不阻止自身断连。真正要关的是：
- 打开连接编辑窗口 → “高级”选项卡
- 取消勾选
自动断开空闲连接（部分版本叫Disconnect when idle，位置可能在“常规”或“高级”页签底部） - 确保
保持连接活跃是勾选状态，并把 ping 间隔设为 60 秒（小于源库wait_timeout的 1/10 更稳妥）
这个选项不显眼，很多用户只调服务端却漏掉它，结果还是同步到一半断连。
同步中途断连后，Navicat 不会自动续传
这是最容易被忽略的关键点：Navicat 的结构或数据同步任务一旦中断，不会记住“已同步到第几行”，而是整个重来。尤其源库有百万级表时，反复重试等于反复扫描全表，加重源库压力，也延长恢复时间。
应对策略不是靠“不断调 timeout”，而是分层规避：
- 对单张大表，改用
mysqldump --where分批次导出，再用 Navicat 导入（适合离线同步） - 启用 MySQL 的
binlog+ 增量同步工具（如 MaxScale、Canal），避开全量拉取场景 - 在 Navicat 数据迁移向导中，勾选
跳过已存在的记录并配合唯一键校验，至少避免主键冲突导致失败
单纯堆高 wait_timeout 只是掩盖问题，不能解决同步不可中断的本质缺陷。
