navicat cloud协作卡在“connecting”主因是mysql的wait_timeout导致连接复用失败；跨地域慢实为dns解析绕路，需手动指定地域endpoint或配置hosts；同步中断常因配额超限而非网络问题；on-prem server更可控但部署要求严格。
为什么Navicat Cloud同步看起来快，但协作时总卡在“Connecting”？
根本原因不是Cloud本身慢，而是你点开表、执行SQL、刷新视图这些操作，全都要重新连一次真实数据库——而这个连接过程被MySQL服务端的wait_timeout机制拖住了。云厂商RDS或企业自建库常把wait_timeout设为60～300秒，闲置后连接被服务端无声断开，Navicat却还拿着旧连接句柄去复用，失败后再重建，就卡住3–10秒。
验证方式很简单：Tools → Connection Properties → Advanced → Keep connection alive勾上，填30，保存重连后立刻点开一张表，看底部状态栏是否跳过“Connecting”直接加载。
注意：Keep connection alive是心跳间隔，不是超时时间；设5会白增请求，设300仍可能掉线。
域名解析绕路才是跨地域同步慢的隐形元凶
别信“自动选最快节点”——Navicat 17 没这逻辑。你配置的rm-xxx.mysql.rds.aliyuncs.com，DNS解析结果完全由本地系统决定。如果它落到新加坡或东京节点，团队里所有人一起绕路。
正确做法只有两个：
- 连接编辑页 → 主机名/IP 地址栏，直接填地域专属 endpoint，例如
rm-xxx-cn-shanghai.mysql.rds.aliyuncs.com - 更彻底：在本地
C:\Windows\System32\drivers\etc\hosts（Windows）或/etc/hosts（macOS/Linux）加一行：10.24.33.12 rm-xxx.mysql.rds.aliyuncs.com（IP替换成你实测低延迟的内网或专线IP）
Navicat Cloud区域设置（比如从US切到CN）对数据库连接速度毫无影响——它只管存你的查询语句和BI看板，不参与任何一次SELECT或DESCRIBE。
同步中断？先查quota exceeded，不是看“同步完成”提示
Navicat Cloud协作版空间不足不会报错，只会静默跳过上传。你以为同步完成了，其实新写的.sql、刚拖进去的.nbi报表、甚至更新过的连接配置，可能根本没传上去。
确认方法有三：
- 打开
Tools → Cloud Sync Status，找状态为Skipped或Failed的条目，点开看详情里有没有quota exceeded - 新建一个1KB的
test.sql，保存到已勾选的同步目录，再点Sync Now，去portal.navicat.com看它是否上线 - 进
Tools → Options → Cloud → Account Info，点Refresh（不点就不会更新配额数字）
占空间最多的是.nbi（BI工作区）、.pipeline（聚合管道）和长期未清理的connections.ncx——单个带快照的BI报表能到5–8MB，且软删除30天内仍计费。
On-Prem Server才是跨地域团队真正可控的选择
如果你的团队对数据主权敏感、已有私有云或IDC、或需要审计日志，Navicat On-Prem Server比Cloud更合适。它不走公有云链路，所有同步流量都在内网或专线中流转。
但部署有硬约束：
- 必须部署在固定内网IP的Linux服务器上（Ubuntu 22.04/CentOS 7.9+），不能装在开发机或笔记本上直曝端口
- Nginx反向代理必须加
proxy_set_header X-Forwarded-Proto $scheme;，否则登录页反复跳转 - 成员必须用组织域邮箱（如
zhangsan@corp.internal）注册，个人Gmail账号无法看到共享对象 - 数据库连接需在Server后台新建并加密同步，不能直接拖本地连接配置过去——否则其他成员点开就是
Connection refused (111)
最易被忽略的一点：Navicat从不自动刷新云端内容。哪怕你刚保存了一个新查询，其他成员不手动右键 → Reload from Cloud，就永远看不到。这不是延迟，是设计如此。
