Navicat定时备份卡在“正在连接”或“执行中”不动的根本原因是GUI封装层等待mysqldump子进程上报进度，而大库导出时stdout几乎无输出导致假死；应改用“运行外部程序”并指定完整路径和重定向参数> /path/to/backup.sql 2>&1，同时禁用自动压缩、改用高速SSD路径、关闭SSH默认压缩并配置ServerAliveInterval保活。
Navicat定时备份卡在“正在连接”或“执行中”不动
这不是数据库没响应，而是 navicat 的 gui 封装层在等 mysqldump（或 pg_dump）子进程主动上报进度，但大库导出时 stdout 几乎不输出，主界面就一直假死。
- 改用「运行外部程序」代替「备份数据库」动作：路径填
mysqldump或pg_dump实际可执行文件路径，参数末尾必须加> /path/to/backup.sql 2>&1，否则 Navicat 会无限等待输出 - 避免使用默认备份路径（如
~/Documents/Navicat/Backup），换成独立 SSD 挂载点（如/Volumes/SSD/backup），顺序写入速度低于 80MB/s 就别硬扛 - 禁用 Navicat 自带压缩：勾选「压缩备份文件」会让导出后多一层 gzip -9，CPU 和 IO 双重阻塞；改用脚本后台跑
gzip -1 backup.sql
走 SSH 隧道时备份超时根本不是数据库问题
SSH 隧道会把所有流量经本地 sshd 转发，而 mysqldump 输出含大量 NULL 字节，OpenSSH 默认启用压缩（Compression yes）反而拖慢吞吐，且空闲超时未配对会导致连接中途断开。
- 在本地 SSH 客户端配置（如
~/.ssh/config）中为跳板机加：ServerAliveInterval 30、ServerAliveCountMax 3、Compression no - 跳板机上检查
/etc/ssh/sshd_config是否有ClientAliveInterval 30，并确认ClientAliveCountMax≥ 3 - Navicat 连接设置里若启用了 SSH 隧道，
Keep Alive参数无效——保活责任已移交 SSH 协议栈
备份过程中报 Lost connection to MySQL server during query
这通常发生在导出大表元数据解析阶段，Navicat 空闲几十秒无数据包发出，中间 NAT 设备（如阿里云 SLB、企业防火墙）直接回收 TCP 连接。
- Navicat 连接页「高级」选项卡中，必须启用
Keep Alive并设为 ≤60 秒（推荐 45），同时取消勾选「仅当有查询时发送 ping」 - 数据库端同步调大
wait_timeout（MySQL）或remote_login_timeout（SQL Server），但仅调服务端无效——中间链路保活必须三端对齐 - 若用 obproxy 连 OceanBase，确认
obproxy进程监听的是2883，且防火墙放行该端口，localhost不能填进 Navicat 的 host 字段
备份目标库在云上却连不通，先别动 Navicat 配置
云环境超时 90% 是安全组或监听绑定问题，不是客户端设置能解决的。
- 在数据库服务器上运行
sudo netstat -tulnp | grep :3306（MySQL）或netsh advfirewall firewall show rule name=all | findstr "1433"（SQL Server），确认端口真正在监听且防火墙放行 - 云平台安全组必须显式允许 TCP 入向流量到对应端口，源 IP 建议先设为
0.0.0.0/0测试，再收敛 - 用 PowerShell 执行
Test-NetConnection your-db-ip -Port 3306，TcpTestSucceeded为 False 时，说明网络层已断，此时调 Navicat 超时时间毫无意义
Keep Alive 设置完全失效，而很多人还在反复调这个参数。真正起作用的是 SSH 的 ServerAliveInterval 和跳板机上的 ClientAliveInterval，二者必须同时存在且数值匹配。
