Navicat同步中断“Lost connection”实为MySQL服务端主动kill连接，因单条操作超wait_timeout（如云RDS默认300秒），需同步调整客户端心跳、SSH保活、SQL mode及提交批次四层配置。
Navicat 同步中途报 “Lost connection to MySQL server during query” 怎么快速定位
这不是网络断了，而是 mysql 主动 kill 了连接——同步大表时，单条 insert 或元数据解析耗时超过 wait_timeout，服务端就断链。错误日志里看不到崩溃记录，show processlist 也查不到残留连接，但 aborted_clients 计数会明显上升。
- 先确认是否真超时：连上数据库执行
SELECT @@wait_timeout, @@max_allowed_packet;，看值是否被云厂商限制（如阿里云 RDS 默认 300 秒） - 别只信 Navicat 界面显示的“正在传输…”——它可能卡在字段类型映射、BLOB 解析或事务提交间隙，期间无 SQL 发出，空闲态直接触发回收
- 用
Test-NetConnection -Port 3306测试端口通，但同步一卡就断，基本锁定为服务端主动断连，不是客户端连不上
Navicat 客户端 Keep-Alive 设置必须配对生效
只勾选「保持连接活跃」但参数设错，等于没开。这个心跳是 TCP 层 ACK 包，专骗 NAT/防火墙/SSH 跳板机，不是发 SELECT 1。
- 路径：编辑连接 → 「高级」选项卡 → 勾选「保持连接活跃」，**取消勾选「仅当有查询时发送 ping」**（同步解析阶段无 query，勾了就失效）
- 间隔设为
60：必须小于云厂商 NAT 超时（阿里云/腾讯云默认 300 秒），但不宜低于15，否则心跳太密干扰连接池 -
连接超时字段（默认30）只管建连阶段，对已建立连接完全无效，别调它来治同步断连
走 SSH 隧道时，SSH 配置比 MySQL 配置还关键
一旦勾了「使用 SSH 隧道」，连接控制权就移交 SSH 协议栈，MySQL 的 wait_timeout 再大也没用——连接早在抵达数据库前就被跳板机回收。
- Navicat 客户端侧：SSH 配置页里填
ServerAliveInterval 30和ServerAliveCountMax 3 - 跳板机（SSH 服务器）侧：编辑
/etc/ssh/sshd_config，加ClientAliveInterval 30和ClientAliveCountMax 3，然后sudo systemctl restart sshd - 禁用小批次提交：
Commit every batch勾选状态要取消，同时把Batch size调大（如10000），避免每百行就触发一次远程事务，放大空闲间隙
外键与 SQL mode 导致的静默中断最容易被忽略
同步失败报错里没提外键，但实际卡在 INSERT INTO users 因 TIMESTAMP 字段传 NULL 被 STRICT_TRANS_TABLES 拦住，只记 warning 不报 error，Navicat 就直接断连。
- 同步前执行
SELECT @@sql_mode;，若含STRICT_TRANS_TABLES，临时关掉：SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION'; - Navicat 同步向导「高级」页里，务必勾选「设置时间戳字段为 CURRENT_TIMESTAMP」
- 结构同步阶段，
Disable foreign key checks选项无效——得手动查INFORMATION_SCHEMA.KEY_COLUMN_USAGE，在对象选择面板里把被引用表拖到引用表上方
