Navicat同步含TEXT/BLOB大字段表时连接超时，本质是客户端中转模式导致内存暴涨、心跳失效及中间链路主动断连，须同步调整MySQL wait_timeout、SSH心跳和Navicat自动重连，并优先启用直接表复制绕过瓶颈。
Navicat 同步含 TEXT/BLOB 的大字段表时连接超时，不是网络断了，而是同步任务在拉取或传输大字段内容过程中被中间链路（SSH、防火墙、MySQL 自身）主动中断——尤其当字段平均长度超 1MB 或单行含 base64 图片、JSON 日志时，极易触发 Lost connection to MySQL server during query 或卡在 1% 不动。
为什么同步 TEXT/BLOB 会触发连接超时？
Navicat 默认用客户端中转模式同步：先从源库 SELECT * 拉全量数据到本地内存，再拼 SQL 写入目标库。TEXT/BLOB 字段不走索引、不压缩、全量加载，导致：
- 内存暴涨，GC 频繁，进程响应变慢，心跳失效
- 单次网络包可能突破
max_allowed_packet，但错误常被掩盖为“连接超时” - MySQL 的
wait_timeout对长查询无效，而大字段读取属于“非空闲态”，服务端可能直接 KILL 连接 - SSH 隧道若未设心跳，30 秒无数据交互即断连，Navicat 不感知
必须同步调整的三项配置（缺一不可）
只调 Navicat 超时时间或只改 MySQL wait_timeout，90% 情况下无效。真正起作用的是这三者的协同：
-
MySQL 层：执行
SET GLOBAL wait_timeout = 28800000（3 小时），并确认interactive_timeout同步设置；若用 Docker 或云 RDS，需进配置文件[mysqld]段写死，否则重启失效 -
SSH 层（如走隧道）：Navicat 连接设置 → SSH → 勾选
Keep alive，间隔填30；同时跳板机上确保/etc/ssh/sshd_config含ClientAliveInterval 30和ClientAliveCountMax 3，并sudo systemctl restart sshd -
Navicat 层：编辑连接 → 高级 → 勾选
Reconnect when connection is lost；不要只依赖“保持连接间隔”，它只发SELECT 1，无法探测已断开但未清理的 TCP 连接
绕过 TEXT/BLOB 同步瓶颈的实操路径
如果只是要数据一致，而非强求用 Navicat GUI 完成，以下方式更快更稳：
- 启用
直接表/视图复制（Structure Synchronization 窗口右下角 Options → 勾选Use direct table copy）：让 MySQL 服务端直连执行INSERT INTO ... SELECT，完全避开本地内存和网络包限制 - 导出为 SQL 文件后用命令行导入：
mysqldump -h src -u user --skip-extended-insert --max-allowed-packet=512M db table > data.sql，再mysql -h dst -u user db - 对超大 TEXT 字段，同步前临时改列类型为
MEDIUMTEXT或加索引提示（如WHERE id BETWEEN ? AND ?分批），避免全表扫描拖垮连接状态
真正容易被忽略的是：Navicat 同步任务一旦启动，就不再检查连接健康度，哪怕中间断了 10 秒，它仍往失效 socket 发数据，直到报错才重连——所以「自动重连」开关必须开，且 SSH 和 MySQL 的保活机制必须跟上，否则永远在重复断连→报错→重试的循环里。
