Navicat 连接 MySQL 延迟高主因是服务端超时断连与客户端重连机制不匹配，需同步调高 wait_timeout/interactive_timeout、启用 Keep-alive、优化 net_buffer_length 和 max_allowed_packet，并检查 SSH 隧道 Nagle 算法影响。
Navicat 连接 MySQL 时延迟高，先查 wait_timeout 和 interactive_timeout
navicat 频繁卡顿、执行语句要等好几秒，大概率不是网络问题，而是服务端主动断连后客户端重连耗时。mysql 默认 wait_timeout 是 28800 秒（8 小时），但 navicat 的「保持连接」逻辑很保守——它会在空闲约 60 秒后发一个 ping，若此时连接已被服务端关闭，就会触发完整 tcp 握手 + 认证流程，延迟直接拉到 1–3 秒。
实操建议：
- 登录 MySQL 执行
SHOW VARIABLES LIKE 'wait_timeout';，确认值是否被调低过（比如设成 60 或 300） - 临时调高：运行
SET SESSION wait_timeout = 28800;（仅当前会话生效） - 永久修改需在
my.cnf中加：wait_timeout = 28800和interactive_timeout = 28800，然后重启 MySQL - Navicat 自身设置里勾选「保持连接活跃」并设为 30 秒（路径：Tools → Options → Connection → Keep-alive ping interval）
用 mysql_real_connect() 连接时未设 MYSQL_OPT_RECONNECT，Navicat 会静默重连失败
Navicat 底层用的是 MySQL C API，而该 API 默认关闭自动重连。一旦连接因超时或网络抖动中断，后续查询会直接报错 MySQL server has gone away，但 Navicat 界面可能只显示「执行中…」卡住，不提示断连。
这不是你能改的代码，但可以反向验证和规避：
- 在 Navicat 中新建连接时，高级选项里勾选「Use compression protocol」——这会间接促使驱动更积极地检测连接状态
- 如果用命令行复现问题，执行
mysql -hxxx -P3306 -uuser -ppass -e "SELECT 1;"后立刻断网再查，能更快暴露该行为 - 真正可控的是服务端：确保
max_allowed_packet足够大（至少 64M），否则大结果集也会触发「gone away」并干扰重连判断
跨系统传输大结果集慢，别只盯 Navicat 设置，先看 net_buffer_length 和 max_allowed_packet
从 Linux 服务器查 10 万行数据，在 Navicat（Windows/macOS）上渲染要 20 秒，往往不是带宽瓶颈，而是 MySQL 分包策略导致大量小包往返。默认 net_buffer_length 是 16K，意味着每行数据若超这个长度，就会被拆成多个网络包发送。
优化方向很具体：
- 查当前值：
SHOW VARIABLES LIKE 'net_buffer_length';，若低于 64K，可临时设为SET SESSION net_buffer_length = 65536; -
max_allowed_packet必须 ≥net_buffer_length，否则前者会强制压回后者值；推荐设为64M（SET GLOBAL max_allowed_packet = 67108864;） - Navicat 的「结果集最大行数」限制（Options → Data Viewing）设太小（如 1000）反而加重压力——它会不断发 LIMIT 查询拼凑全量，不如关掉限制，让服务端一次吐完
- 导出 CSV 时勾选「Use unbuffered result set」（高级选项），避免 Navicat 把整张表 load 到内存再转码
SSH 隧道连远程 MySQL，延迟翻倍？检查 TCP_NODELAY 和本地 ssh_config
用 Navicat 的 SSH 隧道连内网 MySQL，操作响应明显变慢，常见原因是 SSH 层的 Nagle 算法把小包攒起来发，而数据库交互全是短请求，攒包=加延迟。
解决方法在本地 SSH 配置：
- 编辑
~/.ssh/config，对应 Host 块里加：TCPKeepAlive yes和ServerAliveInterval 30 - 关键一行：
SetEnv LANG=en_US.UTF-8（防止字符集协商拖慢首次连接） - 禁用 Nagle：
sudo sysctl -w net.ipv4.tcp_nodelay=1（Linux/macOS 生效，Windows 不支持该参数） - Navicat 隧道设置里不要勾「Compress data during transfer」——SSH 已压缩，再压一次纯属浪费 CPU
跨系统性能问题最麻烦的地方在于：延迟可能同时来自 MySQL 参数、SSH 配置、Navicat 渲染逻辑、甚至本地 DNS 解析顺序。调一个地方没用，得按「连接建立→查询发出→结果返回→界面渲染」四段切开测，否则容易在 wait_timeout 上反复横跳。
