Navicat通过SSH隧道导出数据需确保三者一致：SSH页填跳板机系统信息，常规页主机必须填127.0.0.1（非localhost），MySQL用户权限须授权给跳板机内网IP（如'10.10.5.100'），并配置SSH保活防断连。
能导出，但必须先让 navicat 真正“看到”数据库——ssh 隧道连通 ≠ 数据库可访问，中间卡在权限、地址语义、监听绑定三处。
Navicat 12 的 SSH 隧道配置必须分两页填对
很多人点开连接设置就直接在“常规”页填数据库 IP，结果测试通过却导不出数据。关键在于：SSH 页和常规页的主机名不是一回事，也不能混用。
-
SSH页填的是跳板机（或目标服务器）的系统登录信息：主机填公网 IP（如203.101.55.88），端口填 SSH 端口（默认22），用户名是系统账号（如ubuntu），认证方式选私钥更安全 -
常规页的主机必须填127.0.0.1（不是localhost，也不是内网数据库 IP），端口填 MySQL 实际监听端口（如3306）；填localhost会触发 Unix socket 跳过隧道，导致连接失败 - 如果数据库不在跳板机本机，而在另一台内网机器（如
192.168.1.20），你得在命令行手动建隧道：ssh -L 3307:192.168.1.20:3306 ubuntu@203.101.55.88，然后常规页主机仍填127.0.0.1，端口改填3307
导出前必须确认 MySQL 用户权限绑定了跳板机内网 IP
测试连接成功只说明 SSH 通了，不代表数据库允许这个“来源”登录。经隧道后，MySQL 看到的客户端 IP 是跳板机自身的内网地址（比如 10.10.5.100），不是你的本地电脑 IP。
- 错误做法：
CREATE USER 'exporter'@'localhost'或'exporter'@'%'—— 这两种都匹配不上隧道流量 - 正确做法：显式授权给跳板机 IP，例如
CREATE USER 'exporter'@'10.10.5.100' IDENTIFIED BY 'xxx';，再执行GRANT SELECT ON mydb.* TO 'exporter'@'10.10.5.100'; - 若跳板机内网 IP 不固定，授权子网更稳妥：
'exporter'@'10.10.5.%' - 执行
FLUSH PRIVILEGES;生效，否则权限不生效
Navicat 12 导出 SQL 时容易忽略的稳定性陷阱
导出中途断开、卡在“正在获取表结构”、提示 Lost connection to MySQL server，大概率不是 Navicat 问题，而是 SSH 隧道被中间设备静默回收。
- 现象：刚连上正常，闲置 2–3 分钟后导出失败，重试又暂时恢复
- 根因：云厂商 NAT、企业防火墙、跳板机
sshd_config中的ClientAliveInterval设置过短，主动断开空闲连接 - 临时解法：在 SSH 页勾选“保持连接活跃”，并设为 30 秒（Navicat 12 支持该选项）
- 长期解法：运维在跳板机上调整
/etc/ssh/sshd_config，加两行：ClientAliveInterval 60和ClientAliveCountMax 3，然后sudo systemctl restart sshd
导出动作本身没特殊配置项，但整个链路里最脆弱的一环从来不是 Navicat，而是“谁在连谁”这个基本事实没理清——跳板机 IP、MySQL 绑定地址、用户授权 IP，三者必须逻辑自洽，缺一不可。
