根本原因是navicat默认心跳间隔（240秒）大于mysql服务端超时设置（常为300–600秒），导致连接被服务端提前断开而客户端未感知，引发重连卡顿；需将“保持连接活跃”设为30–60秒、启用use compression、升级navicat或调整mysql 8.0认证插件。
navicat 连接远程数据库慢、闲置后操作卡顿、select 响应延迟高——根本不是软件“性能差”，而是默认配置没适配公网链路的高延迟、中间设备回收连接、服务端超时策略等现实约束。关键动作就三类：调心跳、启压缩、换认证。
为什么勾选“保持连接活跃”并设为 30–60 秒最有效
MySQL 默认 interactive_timeout 是 28800 秒（8 小时），但云厂商或运维常改成 300–600 秒；而 Navicat 默认心跳间隔是 240 秒，一旦服务端先断开连接，Navicat 还拿旧连接发请求，就会卡住重连。这不是网络问题，是客户端和服务端“失联”了。
- 进连接编辑页 → Advanced 标签 → 勾选“保持连接活跃”
- 把“每隔(秒)发送一个ping包”设为
60（保守）或30（推荐，确保小于服务端wait_timeout） - 务必取消勾选“仅当有查询时发送ping”，否则空闲时照样断
- 验证方式：连上后放 5 分钟不动，再点刷新表，响应应在 1 秒内
Use compression 必须开启，尤其跨公网/跨国
Navicat 默认不启用 MySQL 协议层压缩，导致大结果集（比如 SELECT * FROM logs LIMIT 1000）在网络上传输字节数翻倍，延迟直接拉满。启用后，传输量通常减少 60%–90%，对 WAN 效果立竿见影。
- Connection 标签 → 勾选
Use compression - 该选项在 MySQL 5.7+ 和 8.0+ 均原生支持，无需服务端额外配置
- 注意：若服务端禁用了
have_compression（极少见），会静默失效，可用SHOW VARIABLES LIKE 'have_compression'确认
MySQL 8.0+ 认证插件引发握手延迟，必须升级或降级驱动
MySQL 8.0 默认用 caching_sha2_password 插件，Navicat ≤16.0.18 版本握手需两次 round-trip，跨公网时单次连接建立多耗 2–4 秒。这不是密码错，是协议不匹配。
- 方案一（推荐）：升级 Navicat 到
16.1.7+或最新版，已完整兼容 - 方案二：服务端临时切回
mysql_native_password，执行：ALTER USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 方案三：手动更新驱动（Windows 路径：
C:\Program Files\PremiumSoft\Navicat Premium 16\drivers\mysql.jar），替换为mysql-connector-j-8.0.33.jar及以上
导出大表卡在 “Exporting…”？别用 Client export
Navicat 默认导出走的是 Client export：先把全量数据从远端拉到本地内存，再发给目标库。跨系统（如 macOS → 阿里云 ECS）时，本地带宽和内存成瓶颈，100 万行可能卡死。
- Export Wizard → “Export Method” 下拉选
Server export (SQL file) - 目标库需确认
secure_file_priv允许写入（SHOW VARIABLES LIKE 'secure_file_priv'） - 导出格式选 SQL，勾选
Disable foreign key checks和Use extended INSERT
真正容易被忽略的是：这些设置必须每条连接单独配置，不能全局继承；而且“保持连接活跃”对 SSH 隧道连接同样生效——很多人只记得调普通连接，却忘了堡垒机场景下更需要它。
